WireGuard fungerer først når tenaren sender: kunnskap om endepunktet

Tunnelen ser ut til å fungera først når tenaren sender noko først. Start frå klienten og ingenting skjer, vent nokre sekund, prøv igjen og det lukkast. Den vanlege diagnosen er ein øydelagd NAT, og den vanlege diagnosen er feil. Det som endra seg, er at den eine parten lærte kvar den andre bur.

Kunnskap om endepunktet, ikkje tilgjenge

Ein WireGuard-part startar ikkje eit handtrykk før han veit kvar han skal senda det. Konfigurasjonen gjev det som eit endepunkt av adresse og port, og den køyrande tilstanden følgjer endepunktet han trur på no.

wg show skriv ut båe sidene av det biletet, og ein part utan endepunkt i utdata kan ikkje starta noko, uansett kor rett den offentlege nøkkelen og dei tillatne prefiksa er. Samanlikn synet til klienten med synet til tenaren før du endrar noka regle, for dei to er ofte usamde om kven som veit kva.

Korleis ein part lærer eit endepunkt

WireGuard er med vilje stille. Når ein korrekt autentisert pakke kjem frå ei adresse parten ikkje venta, oppdaterer implementasjonen endepunktet til den parten til den nye kjelda, og slik verkar roaming på ein berbar datamaskin som byter nett. Den åtferda forklarar retningsavhenget: dersom tenaren sender først og pakken hans når klienten, lærer klienten den noverande adressa til tenaren og kan svara. Fram til då har han ingen stad å senda. Mekanismen er autentisert roaming og ikkje ein snareveg med tillit ved første bruk, fordi pakken måtte vera gyldig før endepunktet flytta seg.

Verktøydokumentasjonen for wg skildrar den oppdateringa, og han er verdt å lesa ein gong om du skal designa rundt det.

Tilstandsbasert omsetjing legg til si eiga retning

Der UDP går gjennom ein omsetjande gateway, lagar gatewayen tilstand for den første pakken han ser. RFC 4787 skildrar den åtferda og tidsavbrota som til slutt fjernar oppføringa. Ei inaktiv oppføring går ut, og ein innkomande pakke frå den fjerne sida blir då kasta av gatewayen før han når verten. Ein tunnel som verka heile formiddagen sluttar å svara om ettermiddagen nettopp av denne grunnen.

Dette er ein andre og uavhengig mekanisme som gjev det same retningsbestemte symptomet. Både kunnskapen om endepunktet og omsetjingstilstanden må vera rett, og å retta den eine rettar ikkje den andre.

Konfigurer retninga du faktisk vil ha

For ein klient som må starta sambandet, set endepunktet til tenaren i part-seksjonen til klienten og lat det bli der. Å stola på at tenaren sender først er å stola på eit tilfelle i trafikkrekkjefølgja som vil endra seg på eit stille nettverk. Konfigurasjonen bør oppgje den tiltenkte retninga, ikkje oppdaga henne.

For ein part bak omsetjing som må vera tilgjengeleg, slå på ein varig keepalive på den sida. Ein keepalive kvart 25 sekund er den vanlege startverdien, og føremålet er å halda oppføringa open heller enn å testa tunnelen. Vel éi side til å bera han, for aktivering på båe sider doblar trafikken og loggstøyen utan å betra resultatet.

Samanlikn tilstanden før og etter utløysaren

Ta dei to visingane i augneblinken det sviktar, og deretter igjen etter at tenaren sender. Den første kommandoen viser endepunkt og alderen på handtrykket. Den andre viser om det finst ei omsetjingsoppføring for porten. Opptaket viser kva retning som faktisk gjekk over leidningen, og rutesjekken stadfester at klienten ikkje sender den trafikken ein heilt annan stad.

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

Skriv ned endepunktkolonnen og omsetjingsoppføringa saman. Ein part utan endepunkt og ein gateway utan oppføring er to ulike feil. Berre éin av dei blir retta av ein keepalive.