WireGuard deluje šele po tem, ko strežnik pošlje: poznavanje končne točke

Predor se zdi, da deluje šele po tem, ko strežnik prvi nekaj pošlje. Zaženite od odjemalca in nič se ne zgodi, počakajte nekaj sekund, poskusite znova in uspe. Običajna diagnoza je pokvarjen NAT, in običajna diagnoza je napačna. Spremenilo se je to, da je ena stran izvedela, kje živi druga.

Poznavanje končne točke, ne dosegljivost

Stran WireGuarda ne bo začela rokovanja, dokler ne ve, kam ga poslati. Konfiguracija to poda kot končno točko iz naslova in vrat, tekoče stanje pa sledi končni točki, v katero trenutno verjame.

wg show izpiše obe strani te slike, in stran brez končne točke v izpisu ne more ničesar začeti, naj bosta njen javni ključ in dovoljene predpone še tako pravilni. Primerjajte pogled odjemalca s pogledom strežnika, preden spremenite katero koli pravilo, ker se pogosto ne strinjata o tem, kdo kaj ve.

Kako se stran nauči končne točke

WireGuard je namerno tih. Ko pravilno overjen paket prispe z naslova, ki ga stran ni pričakovala, izvedba posodobi končno točko te strani na novi vir, in tako deluje gostovanje na prenosniku, ki menja omrežja. To vedenje pojasnjuje odvisnost od smeri: če strežnik pošlje prvi in njegov paket doseže odjemalca, se odjemalec nauči trenutnega naslova strežnika in lahko odgovori. Do takrat nima kam poslati. Mehanizem je overjeno gostovanje in ne bližnjica zaupanja ob prvi uporabi, ker je moral biti paket veljaven, preden se je končna točka premaknila.

Dokumentacija orodij za wg opisuje to posodobitev, in vredno jo je enkrat prebrati, če boste načrtovali okoli tega.

Prevod s stanjem doda svojo smer

Kjer UDP prehaja skozi prevajalni prehod, prehod ustvari stanje za prvi paket, ki ga vidi. RFC 4787 opisuje to vedenje in časovne omejitve, ki preslikavo sčasoma odstranijo. Nedejavna preslikava poteče, in vhodni paket z oddaljene strani nato prehod zavrže, preden doseže gostitelja. Predor, ki je deloval celo dopoldne, popoldne preneha odgovarjati prav zaradi tega.

To je drugi in neodvisni mehanizem, ki ustvarja enak smerni simptom. Tako poznavanje končne točke kot stanje prevoda morata biti pravilna, in popravljanje enega ne popravi drugega.

Nastavite smer, ki jo resnično želite

Za odjemalca, ki mora začeti povezavo, vstavite končno točko strežnika v razdelek strani odjemalca in jo pustite tam. Zanašanje na to, da bo strežnik poslal prvi, je zanašanje na naključje v vrstnem redu prometa, ki se bo v mirnem omrežju spremenilo. Konfiguracija bi morala navesti predvideno smer, ne pa je odkrivati.

Za stran za prevodom, ki mora ostati dosegljiva, omogočite trajni keepalive na tej strani. Keepalive vsakih 25 sekund je običajna začetna vrednost, njegov namen pa je držati preslikavo odprto, ne preizkušati predora. Izberite eno stran, ki ga bo nosila, ker omogočanje na obeh straneh podvoji promet in hrup v dnevniku, ne da bi izboljšalo rezultat.

Primerjajte stanje pred sprožilcem in po njem

Zajemite oba pogleda v trenutku, ko spodleti, in nato znova po tem, ko strežnik pošlje. Prvi ukaz pokaže končne točke in starost rokovanja. Drugi pokaže, ali za vrata obstaja prevajalni vnos. Zajem pokaže, katera smer je v resnici prešla žico, in preverjanje poti potrdi, da odjemalec tega prometa ne pošilja povsem drugam.

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šite stolpec končne točke in prevajalni vnos skupaj. Stran brez končne točke in prehod brez preslikave sta dve različni napaki. Samo eno od njiju odpravi keepalive.