WireGuard funguje až po odoslaní serverom: znalosť koncového bodu

Tunel vyzerá, že funguje až po tom, čo server ako prvý niečo odošle. Spustite to z klienta a nič sa nedeje, počkajte pár sekúnd, skúste to znova a uspeje. Zvyčajná diagnóza je pokazený NAT a zvyčajná diagnóza je nesprávna. Zmenilo sa to, že jedna strana zistila, kde býva druhá.

Znalosť koncového bodu, nie dosiahnuteľnosť

Strana WireGuardu nezačne podanie ruky, kým nevie, kam ho poslať. Konfigurácia to dodáva ako koncový bod z adresy a portu a bežiaci stav sleduje koncový bod, ktorému práve verí.

wg show vypisuje obe strany tohto obrazu a strana bez koncového bodu vo výstupe nemôže nič začať, nech je jej verejný kľúč a povolené prefixy akokoľvek správne. Porovnajte pohľad klienta s pohľadom servera, skôr než zmeníte akékoľvek pravidlo, pretože obe sa často nezhodujú v tom, kto čo vie.

Ako sa strana dozvie koncový bod

WireGuard je zámerne tichý. Keď dorazí správne autentifikovaný paket z adresy, ktorú strana nečakala, implementácia aktualizuje koncový bod tejto strany na nový zdroj, a tak funguje roaming na notebooku, ktorý mení siete. Toto správanie vysvetľuje závislosť od smeru: ak server odošle prvý a jeho paket dorazí ku klientovi, klient zistí aktuálnu adresu servera a môže odpovedať. Dovtedy nemá kam posielať. Mechanizmus je autentifikovaný roaming, nie skratka dôvery pri prvom použití, pretože paket musel byť platný skôr, než sa koncový bod posunul.

Dokumentácia nástrojov pre wg opisuje tú aktualizáciu a stojí za jedno prečítanie, ak okolo toho budete navrhovať.

Preklad so stavom pridáva vlastný smer

Keď UDP prechádza prekladovou bránou, brána vytvorí stav pre prvý paket, ktorý uvidí. RFC 4787 opisuje toto správanie a časové limity, ktoré mapovanie napokon odstránia. Nečinné mapovanie vyprší a prichádzajúci paket z opačnej strany potom brána zahodí skôr, než dorazí k hostiteľovi. Tunel, ktorý fungoval celé dopoludnie, prestane popoludní odpovedať práve z tohto dôvodu.

Toto je druhý a nezávislý mechanizmus, ktorý vytvára rovnaký smerový príznak. Znalosť koncového bodu aj prekladový stav musia byť správne a oprava jedného neopraví druhé.

Nakonfigurujte smer, ktorý skutočne chcete

Pri klientovi, ktorý musí spojenie začať, vložte koncový bod servera do sekcie strán klienta a nechajte ho tam. Spoliehať sa na to, že server pošle prvý, znamená spoliehať sa na náhodu v poradí prevádzky, ktorá sa v tichej sieti zmení. Konfigurácia má uviesť zamýšľaný smer, nie ho objavovať.

Pri strane za prekladom, ktorá musí zostať dostupná, zapnite na tejto strane trvalý keepalive. Keepalive každých 25 sekúnd je zvyčajná počiatočná hodnota a jeho účelom je držať mapovanie otvorené, nie testovať tunel. Vyberte jednu stranu, ktorá ho ponesie, pretože zapnutie na oboch zdvojnásobí prevádzku aj šum v logu bez zlepšenia výsledku.

Porovnajte stav pred spúšťačom a po ňom

Zachyťte oba pohľady v okamihu zlyhania a potom znova po tom, čo server odošle. Prvý príkaz ukazuje koncové body a vek podania ruky. Druhý ukazuje, či pre port existuje prekladová položka. Zachytenie ukazuje, ktorý smer skutočne prešiel drôtom, a kontrola trasy potvrdzuje, že klient neposiela túto prevádzku niekam úplne inam.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Zapíšte stĺpec koncového bodu a prekladovú položku spolu. Strana bez koncového bodu a brána bez mapovania sú dve rôzne poruchy. Len jednu z nich opraví keepalive.