WireGuard wurket pas nei't de tsjinner stjoert: kennis fan it einpunt

De tunnel liket allinnich te wurkjen neidat de tsjinner earst wat stjoert. Begjin by de klant en der bart neat, wachtsje in pear sekonden, besykje it opnij en it slagget. De gewoane diagnoaze is in brutsen NAT, en de gewoane diagnoaze is ferkeard. Wat feroare is, is dat de iene part leard hat wêr't de oare wennet.

Kennis fan it einpunt, net berikberens

In WireGuard-part sil gjin hânskodding begjinne oant er wit wêr't er it hinne stjoere moat. De konfiguraasje leveret dat as in einpunt fan adres en poarte, en de rinnende tastân folget it einpunt dêr't er op dit stuit yn leaut.

wg show prints beide kanten fan dat byld, en in part sûnder einpunt yn de útfier kin neat begjinne, hoe korrekt syn iepenbiere kaai en tastiene foarheaksels ek binne. Fergelykje de werjefte fan de klant mei dy fan de tsjinner foardat jo in regel feroarje, want de twa binne it faak net iens oer wa't wat wit.

Hoe't in part in einpunt leart

WireGuard is mei opsetsin stil. As in korrekt autentisearre pakket oankomt fan in adres dat it part net ferwachte, fernijt de ymplemintaasje it einpunt fan dat part nei de nije boarne, en sa wurket roaming op in laptop dy't netwurken feroaret. Dat gedrach ferklearret de ôfhinklikens fan de rjochting: as de tsjinner earst stjoert en syn pakket de klant berikt, leart de klant it hjoeddeistige adres fan de tsjinner en kin er antwurdzje. Oant dan hat er gjin plak om hinne te stjoeren. It meganisme is autentisearre roaming en net in flugge wei fan fertrouwen by earst gebrûk, want it pakket moast jildich wêze foardat it einpunt ferhuze.

De dokumintaasje fan de ark foar wg beskriuwt dy fernijing, en it is de muoite wurdich om it ien kear te lêzen as jo dêromhinne gean te ûntwerpen.

Tastânbefettende oersetting foeget syn eigen rjochting ta

Dêr't UDP troch in oersettende poarte giet, makket de poarte tastân oan foar it earste pakket dat er sjocht. RFC 4787 beskriuwt dat gedrach en de tiidgrinzen dy't de kaart úteinlik fuortsmite. In ledige kaart ferrint, en in ynkommend pakket fan de fiere kant wurdt dan troch de poarte weilitten foardat it de host berikt. In tunnel dy't de hiele moarn wurke, hâldt middeis op mei antwurdzjen krekt om dizze reden.

Dit is in twadde en ûnôfhinklik meganisme dat itselde rjochtingssymptoom produsearret. Sawol kennis fan it einpunt as de oersettingstastân moat goed wêze, en it iene reparearje reparearret it oare net.

Konfigurearje de rjochting dy't jo echt wolle

Foar in klant dy't de ferbining begjinne moat, set it einpunt fan de tsjinner yn de part-seksje fan de klant en hâld it dêr. Fertrouwe op de tsjinner om earst te stjoeren is fertrouwe op in tafal yn de folchoarder fan it ferkear dy't feroarje sil op in stil netwurk. De konfiguraasje heart de bedoelde rjochting te neamen, net te ûntdekken.

Foar in part efter oersetting dat berikber bliuwe moat, skeakelje in oanhâldende keepalive yn oan dy kant. In keepalive elke 25 sekonden is de gewoane begjinwearde, en it doel is de kaart iepen hâlde ynstee fan de tunnel te testen. Kies ien kant om it te dragen, want it oan beide kanten ynskeakelje ferdûbelet it ferkear en it lawaai yn de logs sûnder it resultaat te ferbetterjen.

Fergelykje tastân foar en nei de trigger

Fêstlizze de twa werjeften op it momint dat it misrint, en dan wer neidat de tsjinner stjoert. It earste kommando lit einpunten en de âldens fan de hânskodding sjen. It twadde lit sjen oft der in oersettingynfier foar de poarte bestiet. De opname lit sjen hokker rjochting eins oer de tried gie, en de rûtkontrôle befêstiget dat de klant dat ferkear net hielendal earne oars hinne stjoert.

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

Skriuw de einpuntkolom en de oersettingynfier tegearre op. In part sûnder einpunt en in poarte sûnder kaart binne twa ferskillende flaters. Mar ien fan beide wurdt troch in keepalive reparearre.