Jak działa cryptokey routing w WireGuard

Jak działa WireGuard w jednym zdaniu

WireGuard przypisuje każdy pakiet do klucza publicznego. Mechanizm ten nosi nazwę cryptokey routing i stanowi fundament całego projektu: linia AllowedIPs przy danym partnerze (peer) pełni rolę tablicy routingu dla pakietów opuszczających maszynę oraz listy kontroli dostępu dla pakietów przychodzących od tego partnera. Jedno ustawienie, dwa zadania. Należy interpretować AllowedIPs w ten sposób, a każdy plik konfiguracyjny WireGuard stanie się zrozumiały.

Nie istnieje tabela sesji powiązana z adresami IP ani baza danych użytkowników. Partner to klucz publiczny oraz zestaw adresów, których ten klucz może używać. Uzgadnianie połączenia (handshake) oraz liczniki czasu służą utrzymaniu ważności tego powiązania w warunkach zmiennej sieci. Jeśli przed analizą teorii wymagane jest działające połączenie, należy skonfigurować własny serwer VPN WireGuard na VPS, a następnie powrócić do tego miejsca w przypadku niejasności w pliku konfiguracyjnym.

AllowedIPs to tablica routingu i lista kontroli dostępu

Rozważmy najpierw ruch wychodzący. Jądro systemu kieruje pakiet do urządzenia wg0 w standardowy sposób, korzystając z głównej tablicy routingu. WireGuard dopasowuje następnie adres docelowy pakietu do tablicy zawierającej dozwolone prefiksy każdego z peerów, stosując zasadę najdłuższego dopasowania prefiksu. Dopasowanie wskazuje konkretnego peera, co z kolei określa klucz publiczny, klucz sesji oraz punkt końcowy UDP. Pakiet jest szyfrowany dla tego peera i wysyłany pod wskazany adres.

Jeśli żaden wpis AllowedIPs danego peera nie obejmuje adresu docelowego, pakiet nie zostanie wysłany, ponieważ brakuje klucza niezbędnego do jego zabezpieczenia.

ping: sendmsg: Required key not available

Ten błąd oznacza jedno: adres, z którym próbowano się połączyć, nie znajduje się na liście żadnego z peerów. Inny błąd, ping: sendmsg: Destination address required, oznacza, że dopasowano peera, ale WireGuard nie posiada dla niego punktu końcowego, ponieważ nie został on skonfigurowany ani jeszcze wykryty.

Teraz ruch przychodzący. Pakiet UDP dociera na port nasłuchiwania. WireGuard odnajduje sesję na podstawie indeksu odbiorcy w nagłówku, sprawdza licznik względem przesuwnego okna ochrony przed powtórzeniami (replay window), a następnie deszyfruje i uwierzytelnia ładunek. Dopiero po tym kroku odczytywany jest pakiet wewnętrzny, a adres źródłowy tego pakietu musi znajdować się wewnątrz zakresu AllowedIPs przypisanego do wysyłającego peera. Jeśli tak nie jest, pakiet jest odrzucany. Przy włączonym debugowaniu dynamicznym jądro wypisuje przyczynę w wierszu podobnym do poniższego:

wg0: Packet has unallowed src IP (10.8.0.9) from peer 2 (203.0.113.10:51820)

Dlatego peer po stronie serwera otrzymuje /32. Peer skonfigurowany z AllowedIPs = 10.8.0.2/32 może wysyłać pakiety wyłącznie z adresu 10.8.0.2 i żadnego innego. Wpisanie tam 0.0.0.0/0 pozwala temu klientowi na przesyłanie pakietów z dowolnym adresem źródłowym wewnątrz tunelu, w tym z adresem innego klienta.

Nakładające się prefiksy są rozstrzygane na podstawie specyficzności, ponieważ wyszukiwanie opiera się na najdłuższym dopasowaniu prefiksu. Identyczne prefiksy u dwóch różnych peerów zachowują się inaczej: wpis zostaje przypisany do peera skonfigurowanego jako ostatni, a pierwszy peer przestaje otrzymywać ten ruch bez generowania komunikatu o błędzie. Polecenie wg show wg0 allowed-ips wyświetla tablicę faktycznie znajdującą się w jądrze, co jest kluczowe w sytuacjach, gdy plik konfiguracyjny na dysku różni się od aktualnego stanu działania systemu.

Odczyt pliku konfiguracyjnego z uwzględnieniem routingu cryptokey

Strona serwera:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

Strona klienta:

[Interface]
Address = 10.8.0.2/32
PrivateKey = <laptop private key>

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

To samo słowo kluczowe ma przeciwne znaczenie po obu stronach. Na kliencie oznacza ono „wysyłaj każdy cel do tego partnera”. Na serwerze oznacza „akceptuj tylko ten jeden adres od tego partnera”. Asymetria wynika z wartości, a nie z pełnionej roli.

Połowa tych kluczy w ogóle nie należy do protokołu. Address, DNS, MTU, PostUp oraz SaveConfig należą do wg-quick, czyli skryptu powłoki, który uruchamia interfejs. Jądro systemu nigdy ich nie widzi. wg-quick strip wg0 wyświetla zredukowaną konfigurację, którą faktycznie ładuje narzędzie wg, co stanowi najszybszy sposób na zaobserwowanie tego podziału.

Na czym faktycznie polega uzgadnianie połączenia

Uzgadnianie połączenia w WireGuard wykorzystuje protokół Noise_IKpsk2 z frameworka Noise Protocol Framework. Część IK jest istotna dla administratora systemu: statyczny klucz publiczny respondenta jest już znany inicjatorowi, ponieważ stanowi on PublicKey w bloku [Peer], a inicjator przesyła własny statyczny klucz publiczny wewnątrz pierwszej wiadomości w formie zaszyfrowanej. Dzięki temu nie występuje wymiana certyfikatów ani dodatkowa runda komunikacji w celu weryfikacji tożsamości. Pasywny obserwator nie jest w stanie stwierdzić, który klucz nawiązuje połączenie, o ile nie posiada klucza prywatnego respondenta.

Koszt operacji to jedna runda komunikacji. Wiadomość inicjująca ma 148 bajtów, odpowiedź 92 bajty, a przesyłanie danych rozpoczyna się natychmiast po tym procesie. Każda ze stron generuje nową efemeryczną parę kluczy Curve25519 dla każdego uzgadniania, a klucze sesji pochodzą z łańcucha wyników Diffie-Hellman, który łączy klucze statyczne z efemerycznymi. Klucze prywatne efemeryczne są następnie usuwane, co zapewnia utajnienie z wyprzedzeniem (forward secrecy): osoba, która zarejestruje ruch dzisiaj i ukradnie klucz prywatny serwera w przyszłym roku, nadal nie będzie w stanie odczytać zarejestrowanych danych.

Inicjacja uzgadniania zawiera znacznik czasu TAI64N, a każdy peer przechowuje najwyższy znacznik czasu otrzymany od drugiej strony, dzięki czemu powtórzone próby inicjacji są odrzucane. Pakiety danych zawierają 64-bitowy licznik pełniący rolę nonce, a odbiorca utrzymuje przesuwne okno ostatnio widzianych liczników, co pozwala obsługiwać powtórzenia i znaczną zmianę kolejności pakietów bez konieczności utrzymywania stanu połączenia w stylu TCP.

Klucze sesji nie są trwałe, a liczniki czasu są wkompilowane w kod, a nie konfigurowalne.

[
  {
    "label": "REKEY_TIMEOUT",
    "seconds": 5,
    "notes": "resend a handshake initiation that got no answer"
  },
  {
    "label": "KEEPALIVE_TIMEOUT",
    "seconds": 10,
    "notes": "send a keepalive after receiving data and sending none back"
  },
  {
    "label": "REKEY_ATTEMPT_TIME",
    "seconds": 90,
    "notes": "give up on the handshake and report the peer as down"
  },
  {
    "label": "REKEY_AFTER_TIME",
    "seconds": 120,
    "notes": "sender begins a fresh handshake for a new session key"
  },
  {
    "label": "REJECT_AFTER_TIME",
    "seconds": 180,
    "notes": "the old session key is refused and traffic stops"
  }
]

Są to stałe wynikające ze specyfikacji protokołu, a nie pomiary. Ich 5 steruje całym cyklem życia sesji. Po 120 sekundach użycia nadawca rozpoczyna nowe uzgadnianie połączenia, a po 180 sekundach stary klucz jest całkowicie odrzucany, co wstrzymuje ruch do momentu zakończenia nowego uzgadniania. Inicjacja, która nie otrzyma odpowiedzi, jest ponawiana co 5 sekund i porzucana po 90 sekundach. Dlatego wg show wyświetla latest handshake jako wiek względny i dlatego aktywny, poprawnie działający tunel utrzymuje tę wartość na niskim poziomie. Wiek, który rośnie podczas aktywnego przesyłania danych, oznacza, że uzgadnianie połączenia kończy się niepowodzeniem, a nie że tunel jest bezczynny.

Dlaczego peer nie posiada roli klienta ani serwera

Oba końce połączenia uruchamiają identyczny kod i korzystają z tego samego formatu konfiguracji. Tryb serwera nie istnieje. Asymetria, którą można zaobserwować, wynika z Endpoint, a Endpoint jest opcjonalne.

Peer ze skonfigurowanym punktem końcowym (endpoint) może zainicjować uzgadnianie (handshake). Peer bez takiej konfiguracji oczekuje na pierwszy poprawnie uwierzytelniony pakiet, z którego pobiera adres oraz port drugiej strony. Ten wykryty punkt końcowy jest zapisywany i aktualizowany przy każdym otrzymaniu poprawnego pakietu z nowego adresu. W ten sposób działa mechanizm roamingu: laptop zmieniający sieć z Wi-Fi na komórkową utrzymuje ten sam tunel, ponieważ sesja jest identyfikowana za pomocą klucza i indeksu, a nie adresu IP. Żadne połączenie nie jest nawiązywane ponownie, ponieważ w sensie protokołu TCP nigdy nie było ono "połączone".

Ten sam mechanizm prowadzi do istotnego wniosku: peer posiadający publiczny adres zawsze przechowuje ostatni znany publiczny adres IP drugiej strony, a wg show wyświetla tę informację.

Stałe prymitywy, brak negocjacji

WireGuard nie korzysta z list zestawów szyfrów (ciphersuites). Wykorzystuje ChaCha20-Poly1305 do szyfrowania uwierzytelnionego, Curve25519 do uzgadniania kluczy, BLAKE2s do haszowania oraz HKDF do wyprowadzania kluczy. Każde wdrożenie używa tych samych mechanizmów, więc nie występuje faza negocjacji, którą można by przeanalizować, ani ścieżka obniżenia zabezpieczeń do słabszej opcji. Jest to świadomy kompromis: w przypadku złamania jednego z tych prymitywów, rozwiązaniem jest nowa wersja całego protokołu i aktualizacja po obu stronach, a nie zmiana konfiguracji. Ta pojedyncza decyzja eliminuje większość kodu oraz większość typów awarii, które występują w tunelach opartych na TLS, co w głównej mierze stanowi istotę porównania w WireGuard kontra OpenVPN.

Dlaczego port nie odpowiada na skanowanie

Każda wiadomość uzgadniania zawiera pole o nazwie mac1. Jest to kod uwierzytelniania wiadomości (MAC) obliczony dla danej wiadomości przy użyciu klucza wyprowadzonego ze statycznego klucza publicznego odpowiadającego. Nadawca, który nie zna tego klucza publicznego, nie jest w stanie wygenerować poprawnego mac1, a odbiorca odrzuca taki pakiet bez żadnej odpowiedzi. Brak błędu, brak resetu, brak komunikatu ICMP.

Widocznym rezultatem jest skanowanie UDP, które nie zwraca żadnych danych.

sudo nmap -sU -p 51820 vpn.example.com

Narzędzie nmap raportuje open|filtered, co jest taką samą odpowiedzią, jaką zwraca dla portu, który jest cicho odrzucany przez firewall. Port zachowuje się identycznie niezależnie od tego, czy WireGuard nasłuchuje, czy nie – przynajmniej z perspektywy każdego, kto nie posiada Twojego klucza publicznego.

Drugie pole, mac2, obsługuje ochronę przed atakami typu denial of service. Gdy odbiorca jest pod dużym obciążeniem, odpowiada na poprawne zainicjowanie 64-bajtową odpowiedzią typu cookie, powiązaną z adresem źródłowym nadawcy. Odbiorca odmawia wykonywania kosztownych operacji na kluczach publicznych, dopóki nadawca nie odeśle tego cookie z powrotem. Potwierdza to, że adres źródłowy jest prawdziwy, zanim zostaną na niego zużyte zasoby procesora; mechanizm ten aktywuje się wyłącznie pod obciążeniem.

Dlaczego 0.0.0.0/0 zmienia peer w domyślną trasę

Ponieważ AllowedIPs stanowi tablicę routingu, AllowedIPs = 0.0.0.0/0, ::/0 przejmuje każdy cel dla tego peera. Jest to pełne ustawienie tunelu.

Mechanizm routingu, który to umożliwia, jest bardziej złożony niż sama linia konfiguracji. Zwykła domyślna trasa przez wg0 spowodowałaby pętlę, ponieważ zaszyfrowany pakiet UDP przenoszący ruch również musi opuścić maszynę i pasowałby do własnej trasy domyślnej. wg-quick unika tego problemu dzięki policy routing. Oznacza własne pakiety wychodzące WireGuard za pomocą fwmark, umieszcza domyślną trasę tunelu w oddzielnej tablicy routingu i dodaje reguły tak, aby trafiał do niej tylko ruch nieoznaczony. Uruchom ip rule show, aby zobaczyć wynik:

32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main

0xca6c to 51820 w systemie szesnastkowym, a 51820 to również numer tablicy. Reguła suppress_prefixlength 0 sprawia, że główna tablica pomija własną trasę domyślną, dzięki czemu konkretne trasy, takie jak lokalna podsieć, nadal mają pierwszeństwo, podczas gdy cały pozostały ruch trafia do tablicy tunelu. Split tunnel nie wymaga żadnego z tych działań: węższa lista, taka jak AllowedIPs = 10.8.0.0/24, 10.20.0.0/16, staje się zwykłymi trasami w głównej tablicy.

Jedną z rzeczy, której pełny tunel nie naprawia samodzielnie, jest rozpoznawanie nazw, ponieważ resolver, który klient otrzymał z sieci lokalnej, zazwyczaj pozostaje aktywny, a trasa do niego jest bardziej szczegółowa. Jest to oddzielne zadanie, opisane w DNS wyciekający poza tunel WireGuard.

Do czego faktycznie służy PersistentKeepalive

WireGuard nie wysyła żadnych danych, gdy ruch nie występuje. Brak sygnałów typu heartbeat, odświeżania sesji czy jakiejkolwiek aktywności w sieci. Ta cisza sprzyja oszczędzaniu baterii i pomaga w scenariuszu skanowania opisanym powyżej, jednak powoduje problemy w jednej konkretnej konfiguracji.

Peer znajdujący się za NAT (network address translation) lub za stanowym firewallem jest osiągalny z zewnątrz tylko wtedy, gdy w urządzeniu istnieje odpowiednie mapowanie, utworzone przez pakiet wychodzący. Typowy czas życia mapowania UDP zaczyna się od około 30 sekund. Gdy mapowanie wygasa, pakiety z publicznej strony są odrzucane przez urządzenie pośredniczące, a tunel wydaje się nieaktywny, dopóki peer za NAT nie wyśle jakichkolwiek danych. PersistentKeepalive = 25 wysyła pusty, uwierzytelniony pakiet co 25 sekund, co mieści się w najkrótszym typowym czasie życia mapowania, dzięki czemu pozostaje ono otwarte.

Opcję tę należy ustawić na peerze znajdującym się za NAT. Serwer z publicznym adresem i otwartym portem UDP jej nie potrzebuje, a jej włączenie generuje jedynie niepotrzebny ruch. Nie należy mylić tego mechanizmu z automatycznym keepalive, który uruchamia się 10 sekund po tym, jak peer otrzyma dane i nie ma własnych informacji do odesłania. Ten mechanizm jest zawsze aktywny i nie podlega konfiguracji.

Kierowanie ruchu sieci lokalnej przez tunel nie jest funkcją WireGuard

Załóżmy, że peer B znajduje się w sieci domowej 192.168.50.0/24, a peer A powinien mieć do niej dostęp. Dwa odrębne systemy muszą zostać skonfigurowane, przy czym tylko jeden z nich to WireGuard.

Część dotycząca WireGuard: należy dodać 192.168.50.0/24 do sekcji AllowedIPs peera B na hoście A. Powoduje to, że A kieruje prefiks do B oraz akceptuje pakiety z tymi adresami źródłowymi przychodzące od B. Bez tego mechanizm cryptokey routing nie posiada klucza dla miejsca docelowego ani uprawnień dla źródła.

Część dotycząca jądra systemu: na hoście B parametr net.ipv4.ip_forward musi mieć wartość 1, w przeciwnym razie jądro odrzuci każdy odszyfrowany pakiet, który nie jest zaadresowany bezpośrednio do B. Łańcuch forward firewalla na hoście B musi zezwalać na ten ruch. Hosty w sieci lokalnej wymagają trasy powrotnej do 10.8.0.0/24, w przeciwnym razie B musi zastosować source NAT, aby odpowiedzi wracały przez B.

Zadanie WireGuard kończy się w momencie przekazania odszyfrowanego pakietu do jądra systemu. Wszystko, co dzieje się później, to standardowe routowanie i filtrowanie w systemie Linux. Dlatego ten błąd jest widoczny w licznikach nft list ruleset lub w ip -s link show wg0, a nie w wg show. Jeśli preferowane jest zarządzanie peerami przez interfejs WWW, uruchomienie wg-easy w Docker wygeneruje wpisy peerów automatycznie, jednak reguły przekierowania nadal muszą zostać skonfigurowane na hoście.

Dlaczego WireGuard działa w jądrze systemu

wg0 to sterownik urządzenia sieciowego. Pakiety docierają do niego poprzez standardowy stos routingu, są szyfrowane w kontekście softirq i opuszczają system przez gniazdo UDP, nigdy nie przechodząc do przestrzeni użytkownika. Z tego wynika wysoka przepustowość oraz fakt, że moduł liczy około czterech tysięcy linii kodu, co pozwala na jego weryfikację i włączenie do głównej linii Linux 5.6 w marcu 2020 roku. Ubuntu 24.04 oraz Debian 13 dostarczają to rozwiązanie, więc brakuje jedynie pakietu wireguard-tools.

Działanie jako standardowy interfejs ma praktyczne konsekwencje. tcpdump -ni wg0 pokazuje niezaszyfrowane pakiety wewnętrzne, podczas gdy tcpdump -ni eth0 udp port 51820 prezentuje zaszyfrowane pakiety zewnętrzne; porównanie obu pozwala natychmiast ustalić, w którym kierunku występuje awaria. netfilter oraz mechanizmy kształtowania ruchu traktują wg0 jak każde inne łącze. W sytuacjach, gdy moduł jądra jest niedostępny, na przykład w wirtualizacji kontenerowej współdzielącej jądro hosta, wireguard-go implementuje ten sam protokół w przestrzeni użytkownika za pośrednictwem urządzenia TUN, co wiąże się z realnym spadkiem przepustowości, ponieważ każdy pakiet dwukrotnie przekracza granicę jądra.

Przed czym WireGuard nie chroni

Model zagrożeń jest celowo wąski, a tak dyskretny protokół sprzyja myśleniu życzeniowemu. Należy to jasno określić.

• Nie ukrywa faktu korzystania z WireGuard. Komunikaty uzgadniania mają stałe rozmiary, pierwszy bajt określa typ komunikatu, a transport odbywa się przez UDP. Mechanizmy DPI (Deep Packet Inspection) łatwo go rozpoznają, a sieć blokująca VPN może go zablokować. Obfuskację pominięto w fazie projektowania.
• Nie ukrywa wolumenu ani czasu transmisji. Ładunki są dopełniane tylko do granicy 16 bajtów, więc obserwator nadal widzi, kiedy wysyłasz dane i w przybliżeniu, jak dużo.
• Przechowuje ostatni znany punkt końcowy. Peer z publicznym adresem przechowuje bieżący publiczny adres IP drugiej strony, a wg show go wyświetla. W połączeniu ze stałym adresem tunelu w konfiguracji, stanowi to stabilny identyfikator podążający za użytkownikiem między sieciami. Na własnym VPS jest to akceptowalne. Jest to również powód, dla którego usługi komercyjne dodają warstwę powyżej protokołu.
• Uwierzytelnia klucz, a nie osobę. Peerem jest każdy, kto posiada plik klucza prywatnego. Utrzymuj /etc/wireguard w trybie 700, a pliki kluczy w trybie 600.
• Brak listy unieważnień oraz dat wygaśnięcia. Dostęp kończy się w momencie usunięcia wpisu peera z każdego serwera, który go posiada, a statyczne klucze są aktywne do momentu ich usunięcia.

Nic z powyższych nie czyni WireGuard słabym. Czyni go małym, a o to właśnie chodzi: uwierzytelnia i szyfruje, pozostawiając zarządzanie tożsamością oraz przydzielanie adresów rozwiązaniom zbudowanym powyżej. Warstwa koordynacyjna, taka jak opisana w Porównanie WireGuard z Tailscale, istnieje, aby wypełnić dokładnie tę lukę, wykorzystując tę samą płaszczyznę danych, o której właśnie przeczytano.

FAQ

Czym jest routing cryptokey w WireGuard?

Routing cryptokey to zasada przypisująca każdy pakiet do klucza publicznego. Każdy wpis peer zawiera listę prefiksów w AllowedIPs. W ruchu wychodzącym WireGuard wybiera peer poprzez dopasowanie miejsca docelowego pakietu do listy każdego z peerów, zaczynając od najdłuższego prefiksu, dzięki czemu lista pełni funkcję tablicy routingu. W ruchu przychodzącym, po odszyfrowaniu i uwierzytelnieniu pakietu, jego wewnętrzny adres źródłowy musi znajdować się na liście tego samego peera, w przeciwnym razie pakiet zostanie odrzucony; lista pełni więc również funkcję listy kontroli dostępu. WireGuard nie posiada oddzielnej konfiguracji routingu ani wewnętrznego firewalla, ponieważ ta jedna lista realizuje oba te zadania.

Czy muszę ustawiać PersistentKeepalive na obu peerach?

Nie. Należy to ustawić po stronie znajdującej się za NAT (network address translation) lub za stanowym firewallem, co zazwyczaj dotyczy klienta. WireGuard nie wysyła żadnych danych w stanie bezczynności, więc mapowanie pozwalające drugiej stronie na dotarcie do peera wygasa, często w ciągu minuty, przez co tunel wydaje się nieaktywny w jednym kierunku. PersistentKeepalive = 25 wysyła pusty, uwierzytelniony pakiet co 25 sekund, co utrzymuje mapowanie w stanie otwartym. Peer z publicznym adresem i otwartym portem UDP nie potrzebuje tego ustawienia.

Dlaczego ping przez tunel zwraca błąd "Required key not available"?

Ponieważ adres docelowy nie znajduje się w żadnym AllowedIPs żadnego z peerów, więc routing cryptokey nie znalazł klucza do zaszyfrowania pakietu, a jądro odmówiło jego wysłania. Uruchom wg show wg0 allowed-ips i porównaj wynik z adresem, który próbujesz pingować. Podobny błąd Destination address required oznacza inny problem: peer został dopasowany, ale WireGuard nie posiada dla niego punktu końcowego (endpoint), ponieważ nie został on skonfigurowany, a od tego peera nie nadszedł jeszcze żaden uwierzytelniony pakiet.

Czy firewall może wykryć i zablokować WireGuard?

Tak. WireGuard uwierzytelnia i szyfruje ruch, nie podejmując prób ukrycia swojej obecności. Komunikaty handshake mają stałą długość 148 i 92 bajtów, pierwszy bajt każdego komunikatu identyfikuje jego typ, a transport odbywa się przez UDP, więc inspekcja głęboka pakietów (DPI) bez trudu identyfikuje ten protokół. Sieci blokujące UDP lub stosujące fingerprinting protokołów zablokują połączenie. Ukrycie tunelu wymaga owinięcia go w inny protokół, co stanowi zadanie dla zewnętrznego narzędzia, a nie ustawienia wewnątrz WireGuard.