WireGuard funguje až poté, co server odešle: znalost koncového bodu

Tunel vypadá, že funguje jen poté, co server nejdřív něco odešle. Spusťte to z klienta a nic se neděje, počkejte pár sekund, zkuste to znovu a uspěje. Obvyklá diagnóza je rozbitý NAT a obvyklá diagnóza je špatná. Změnilo se to, že se jeden protějšek dozvěděl, kde bydlí ten druhý.

Znalost koncového bodu, ne dosažitelnost

Protějšek WireGuardu nezahájí handshake, dokud neví, kam ho poslat. Konfigurace to dodává jako koncový bod z adresy a portu a běžící stav sleduje koncový bod, kterému právě věří.

wg show vypisuje obě strany tohoto obrázku a protějšek bez koncového bodu ve výstupu nemůže nic zahájit, ať jsou jeho veřejný klíč a povolené prefixy jakkoli správné. Porovnejte pohled klienta s pohledem serveru, než změníte jakékoli pravidlo, protože oba se často neshodnou v tom, kdo co ví.

Jak se protějšek dozví koncový bod

WireGuard je záměrně tichý. Když dorazí správně autentizovaný paket z adresy, kterou protějšek nečekal, implementace aktualizuje koncový bod tohoto protějšku na nový zdroj, a tak funguje roaming na notebooku, který mění sítě. Toto chování vysvětluje závislost na směru: pokud server odešle první a jeho paket dorazí ke klientovi, klient se dozví aktuální adresu serveru a může odpovědět. Do té doby nemá kam posílat. Mechanismus je autentizovaný roaming, nikoli zkratka důvěry při prvním použití, protože paket musel být platný dřív, než se koncový bod posunul.

Dokumentace nástrojů pro wg toto aktualizování popisuje a stojí za jedno přečtení, pokud kolem toho budete navrhovat.

Překlad se stavem přidává vlastní směr

Když UDP prochází překladovou bránou, brána vytvoří stav pro první paket, který uvidí. RFC 4787 popisuje toto chování a časové limity, které mapování nakonec odstraní. Nečinné mapování vyprší a příchozí paket z opačné strany pak brána zahodí dřív, než dorazí k hostiteli. Tunel, který fungoval celé dopoledne, přestane odpoledne odpovídat právě z tohoto důvodu.

Toto je druhý a nezávislý mechanismus, který vytváří stejný směrový příznak. Znalost koncového bodu i překladový stav musí být správné a oprava jednoho neopraví druhé.

Nakonfigurujte směr, který skutečně chcete

U klienta, který musí spojení zahajovat, vložte koncový bod serveru do sekce protějšků klienta a nechte ho tam. Spoléhat na to, že server pošle první, znamená spoléhat na náhodu v pořadí provozu, která se v tiché síti změní. Konfigurace má uvádět zamýšlený směr, ne ho objevovat.

U protějšku za překladem, který musí zůstat dostupný, zapněte na této straně trvalý keepalive. Keepalive každých 25 sekund je obvyklá počáteční hodnota a jeho účelem je držet mapování otevřené, ne testovat tunel. Vyberte jednu stranu, která ho ponese, protože zapnutí na obou zdvojnásobí provoz i šum v logu, aniž by zlepšilo výsledek.

Porovnejte stav před spouštěčem a po něm

Zachyťte oba pohledy v okamžiku selhání a pak znovu poté, co server odešle. První příkaz ukazuje koncové body a stáří handshake. Druhý ukazuje, zda pro port existuje překladová položka. Zachycení ukazuje, který směr skutečně přešel drátem, a kontrola trasy potvrzuje, že klient tento provoz neposílá někam úplně jinam.

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

Zapište sloupec koncového bodu a překladovou položku společně. Protějšek bez koncového bodu a brána bez mapování jsou dvě různé závady. Jen jednu z nich opraví keepalive.