Jak działa cryptokey routing w WireGuard

Jak działa WireGuard w jednym zdaniu

WireGuard przypisuje każdy pakiet do klucza publicznego. Mechanizm ten nazywa się cryptokey routing i stanowi podstawę 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, z których ten klucz może korzystać. Mechanizm uzgadniania (handshake) oraz liczniki czasu służą utrzymaniu tego powiązania w sytuacji, gdy sieć bazowa ulega zmianom. Jeśli przed zgłębianiem teorii potrzebny jest działający tunel, należy skonfigurować własny serwer VPN WireGuard na VPS, a następnie wrócić tutaj, gdy któraś z linii konfiguracji okaże się niejasna.

AllowedIPs to tablica routingu i lista kontroli dostępu

W kierunku wychodzącym proces przebiega następująco. Jądro systemu kieruje pakiet do urządzenia wg0 w standardowy sposób, korzystając z głównej tablicy routingu. Następnie WireGuard dopasowuje adres docelowy pakietu do tablicy zawierającej dozwolone prefiksy wszystkich peerów, stosując zasadę najdłuższego dopasowania prefiksu. Znalezienie dopasowania 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 zaszyfrowania.

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 peera. 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.

W kierunku przychodzącym pakiet UDP dociera na port nasłuchiwania. WireGuard odnajduje sesję na podstawie indeksu odbiorcy w nagłówku, sprawdza licznik względem przesuwnego okna zabezpieczającego przed atakami typu replay, a następnie deszyfruje i uwierzytelnia ładunek. Dopiero po tym kroku odczytywany jest pakiet wewnętrzny, a jego adres źródłowy musi mieścić się w zakresie AllowedIPs peera wysyłającego. 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 adresami należącymi do innych klientów.

Nakładające się prefiksy są rozstrzygane na podstawie szczegółowości, zgodnie z zasadą najdłuższego dopasowania 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ę aktualnie załadowaną w jądrze, co jest kluczowe w sytuacjach, gdy stan pliku na dysku różni się od stanu działającej usługi.

Odczytywanie 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, 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 wczytuje narzędzie wg, co stanowi najszybszy sposób na zaobserwowanie tego podziału.

Na czym polega proces uzgadniania połączenia

Uzgadnianie połączenia w WireGuard opiera się na protokole Noise_IKpsk2 z frameworka Noise Protocol Framework. Część IK jest istotna z punktu widzenia administratora: statyczny klucz publiczny respondenta jest 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 potwierdzenia tożsamości. Obserwator pasywny nie jest w stanie zidentyfikować klucza wywołującego, o ile nie posiada klucza prywatnego respondenta.

Koszt operacji to jedna runda komunikacji. Wiadomość inicjująca ma rozmiar 148 bajtów, odpowiedź 92 bajty, a przesył danych rozpoczyna się natychmiast po tym procesie. Każda ze stron generuje nową efemeryczną parę kluczy Curve25519 dla każdego uzgodnienia, a klucze sesyjne powstają z łańcucha wyników Diffie-Hellman, który łączy klucze statyczne z efemerycznymi. Efemeryczne klucze prywatne są następnie usuwane, co zapewnia tzw. forward secrecy: osoba, która zarejestruje ruch dzisiaj i w przyszłości przejmie klucz prywatny serwera, nadal nie będzie w stanie odszyfrować zarejestrowanych danych.

Inicjacja uzgodnienia zawiera znacznik czasu TAI64N, a każdy z węzłów przechowuje najwyższy dotychczas odebrany znacznik czasu od partnera, co pozwala odrzucić powtórzone (replayed) próby inicjacji. Pakiety danych zawierają 64-bitowy licznik pełniący rolę nonce, a odbiorca utrzymuje przesuwne okno ostatnio widzianych liczników. Dzięki temu powtórzenia i znaczna zmiana kolejności pakietów są obsługiwane bez konieczności utrzymywania stanu połączenia w stylu TCP.

Klucze sesyjne mają krótki czas życia, a wartości czasowe są zaszyte w kodzie, 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, a po 180 sekundach stary klucz jest całkowicie odrzucany, co wstrzymuje ruch do czasu zakończenia nowego uzgodnienia. Inicjacja, która pozostaje bez odpowiedzi, jest ponawiana co 5 sekund i porzucana po 90 sekundach. Z tego powodu wg show wyświetla latest handshake jako wiek względny i dlatego w aktywnym, poprawnie działającym tunelu wartość ta pozostaje niska. Wiek rosnący podczas aktywnego przesyłania danych oznacza, że uzgadnianie połączenia kończy się niepowodzeniem, a nie że tunel jest bezczynny.

Dlaczego peer nie pełni 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óra jest odczuwalna, wynika z Endpoint, a Endpoint jest opcjonalne.

Peer ze skonfigurowanym endpointem może zainicjować uzgadnianie (handshake). Peer bez takiej konfiguracji oczekuje na pakiet, a następnie odczytuje adres i port drugiej strony z pierwszego poprawnie uwierzytelnionego pakietu. Ten poznany endpoint jest zapisywany i aktualizowany przy każdym otrzymaniu poprawnego pakietu z nowego adresu. W ten sposób działa roaming: laptop zmieniający sieć z Wi-Fi na mobilną utrzymuje ten sam tunel, ponieważ sesja jest identyfikowana za pomocą klucza i indeksu, a nie adresu IP. Żadne połączenie nie jest wznawiane, ponieważ w sensie TCP nigdy nie było ono nawiązane.

Ten sam mechanizm tworzy fakt, o którym warto wiedzieć: peer z publicznym adresem zawsze przechowuje ostatni znany publiczny adres IP drugiej strony, a wg show wyświetla go.

Stałe prymitywy kryptograficzne bez negocjacji

W WireGuard nie istnieje lista pakietów szyfrów (ciphersuite). Protokół wykorzystuje ChaCha20-Poly1305 do szyfrowania uwierzytelnionego, Curve25519 do uzgadniania kluczy, BLAKE2s do haszowania oraz HKDF do wyprowadzania kluczy. Każde wdrożenie korzysta z tych samych rozwiązań, dlatego 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, naprawa wymaga wydania nowej wersji całego protokołu i aktualizacji po obu stronach, a nie zmiany konfiguracji. Ta pojedyncza decyzja eliminuje większość kodu oraz większość trybów awarii typowych dla tuneli opartych na TLS, co stanowi główny punkt porównania w WireGuard kontra OpenVPN.

Dlaczego port nie odpowiada na skanowanie

Każdy komunikat uzgadniania zawiera pole o nazwie mac1. Jest to kod MAC (message authentication code) obliczony dla komunikatu przy użyciu klucza wywiedzionego 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 otrzymuje żadnej odpowiedzi.

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 obciążenie typu denial of service. Gdy odbiorca jest pod obciążeniem, odpowiada na poprawne zainicjowanie 64-bajtową odpowiedzią typu cookie, powiązaną z adresem źródłowym nadawcy, i 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, a 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łna konfiguracja tunelu.

Mechanizm routingu, który to umożliwia, jest bardziej złożony niż sama linia konfiguracji. Zwykła trasa domyślna 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 wychodzące pakiety WireGuard za pomocą fwmark, umieszcza trasę domyślną tunelu w osobnej tablicy routingu i dodaje reguły tak, aby trafiał do niej tylko nieoznaczony ruch. 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 formacie 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órego klient nauczył się z sieci lokalnej, zazwyczaj pozostaje aktywny, a trasa do niego jest bardziej szczegółowa. Jest to osobne zadanie, opisane w DNS wyciekający poza tunel WireGuard.

Do czego faktycznie służy PersistentKeepalive

WireGuard nie wysyła żadnych danych, gdy brak jest ruchu sieciowego. Brak sygnałów typu heartbeat, odświeżania sesji czy jakiejkolwiek aktywności w łączu. Ta cisza sprzyja oszczędzaniu baterii oraz 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.

Parametr ten należy ustawić na peerze znajdującym się za NAT. Serwer z publicznym adresem i otwartym portem UDP go nie potrzebuje, a jego ustawienie tam jedynie generuje niepotrzebny ruch. Nie należy mylić tego z automatycznym mechanizmem keepalive, który uruchamia się 10 sekund po tym, jak peer otrzyma dane i nie ma nic własnego do odesłania. Ten mechanizm jest zawsze włączony i nie podlega konfiguracji.

Routing sieci LAN 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 oddzielne systemy muszą zostać skonfigurowane, przy czym tylko jeden z nich to WireGuard.

Część dotycząca WireGuard: dodaj 192.168.50.0/24 do AllowedIPs peera B w konfiguracji peera A. Dzięki temu A kieruje prefiks do B i 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 LAN wymagają trasy powrotnej do 10.8.0.0/24 lub host B musi zastosować source NAT, aby odpowiedzi wracały przez B.

Zadanie WireGuard kończy się w momencie przekazania odszyfrowanego pakietu do jądra. Wszystko, co dzieje się później, podlega standardowemu routingowi i filtrowaniu Linuksa. Dlatego ten problem 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 Dockerze automatycznie generuje wpisy peerów, ale reguły przekazywania nadal należą do hosta. Ten sam podział obowiązuje, gdy warstwa koordynacyjna rozsyła prefiks automatycznie: reklamowanie prywatnej sieci z VPS za pomocą routera podsieci Tailscale zastępuje ręczną edycję AllowedIPs na każdym peerze, ale sysctl odpowiedzialny za przekazywanie pakietów oraz reguły zapory na samym routerze nadal trzeba skonfigurować ręcznie.

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 (userspace). To właśnie zapewnia wysoką przepustowość i sprawia, że moduł liczy około czterech tysięcy linii kodu, co pozwala na jego łatwą weryfikację i włączenie do głównej linii jądra Linux 5.6 w marcu 2020 roku. Systemy Ubuntu 24.04 oraz Debian 13 dostarczają go w standardzie, 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 wyświetla zaszyfrowane pakiety zewnętrzne; porównanie obu pozwala natychmiast ustalić, w którym kierunku występuje awaria. Mechanizmy netfilter oraz kształtowanie ruchu (traffic shaping) traktują wg0 jak każde inne łącze. W środowiskach, gdzie 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 odciąć. Obfuskacja została celowo pominięta w projekcie.
• Nie ukrywa wolumenu ani czasu przesyłu danych. Ł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 zapisuje bieżące publiczne IP drugiej strony, a wg show je wyświetla. W połączeniu z adresem tunelu, który jest stały 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, nie osobę. Każdy, kto posiada plik klucza prywatnego, jest peerem. Utrzymuj /etc/wireguard w trybie 700, a pliki kluczy w 600.
• Nie istnieje lista unieważnień ani wygasanie. Dostęp kończy się w momencie usunięcia wpisu peera z każdego serwera, który go posiada, a statyczne klucze są ważne do momentu ich usunięcia.

Nic z powyższych nie czyni WireGuard słabym. Czyni go to małym, a mały rozmiar jest celem: protokół uwierzytelnia i szyfruje, pozostawiając zarządzanie tożsamością i przydzielanie adresów rozwiązaniom budowanym powyżej. Warstwa koordynacyjna, taka jak opisana w WireGuard w porównaniu z Tailscale, istnieje, aby wypełnić dokładnie tę lukę, wykorzystując tę samą płaszczyznę danych, o której właśnie przeczytałeś. Gdy taka warstwa jest już wdrożona, kolejną decyzją jest to, kto może uzyskać dostęp do usługi uruchomionej wewnątrz tunelu, co rozstrzyga wybór między Tailscale serve a funnel dla pojedynczego portu.

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 adresu docelowego pakietu do listy każdego z peerów, stosując zasadę 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 jest odrzucany, więc lista pełni 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 ustawić tę opcję po stronie znajdującej się za NAT (network address translation) lub za firewallem stanowym, 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, co sprawia, że tunel wydaje się nieaktywny w jednym kierunku. PersistentKeepalive = 25 wysyła pusty, uwierzytelniony pakiet co 25 sekund i utrzymuje mapowanie jako aktywne. Peer z publicznym adresem i otwartym portem UDP nie potrzebuje tej opcji.

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

Ponieważ adres docelowy nie znajduje się wewnątrz żadnego AllowedIPs zdefiniowanego dla 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 jest pingowany. 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 i żaden uwierzytelniony pakiet nie dotarł jeszcze od tego peera.

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 jego opakowania w inny protokół, co jest zadaniem dla zewnętrznych narzędzi, a nie ustawieniem samego WireGuard.