WireGuard fungerer først når serveren sender: kunnskap om endepunktet
Suksess som avhenger av retningen betyr vanligvis at den ene parten aldri lærte den andres adresse. Sammenlign endepunktene, og sjekk deretter om en oversettelsesoppføring er utløpt.
Tunnelen ser ut til å virke først når serveren sender noe først. Start fra klienten og ingenting skjer, vent noen sekunder, prøv igjen og det lykkes. Den vanlige diagnosen er en ødelagt NAT, og den vanlige diagnosen er feil. Det som endret seg, er at den ene parten lærte hvor den andre bor.
Kunnskap om endepunktet, ikke tilgjengelighet
En WireGuard-part starter ikke et håndtrykk før den vet hvor den skal sende det. Konfigurasjonen leverer det som et endepunkt av adresse og port, og den kjørende tilstanden følger endepunktet den for øyeblikket tror på.
wg show skriver ut begge sider av det bildet, og en part uten endepunkt i utdataene kan ikke starte noe, uansett hvor korrekt den offentlige nøkkelen og de tillatte prefiksene er. Sammenlign klientens syn med serverens før du endrer noen regel, for de to er ofte uenige om hvem som vet hva.
Hvordan en part lærer et endepunkt
WireGuard er med vilje stille. Når en korrekt autentisert pakke ankommer fra en adresse parten ikke forventet, oppdaterer implementasjonen den partens endepunkt til den nye kilden, og det er slik roaming virker på en bærbar datamaskin som bytter nettverk. Den oppførselen forklarer retningsavhengigheten: hvis serveren sender først og pakken når klienten, lærer klienten serverens nåværende adresse og kan svare. Inntil da har den ingen steder å sende. Mekanismen er autentisert roaming og ikke en snarvei med tillit ved første bruk, fordi pakken måtte være gyldig før endepunktet flyttet seg.
Verktøydokumentasjonen for wg beskriver den oppdateringen, og den er verdt å lese én gang hvis du skal designe rundt det.
Tilstandsbasert oversettelse legger til sin egen retning
Der UDP passerer en oversettende gateway, oppretter gatewayen tilstand for den første pakken den ser. RFC 4787 beskriver den oppførselen og tidsavbruddene som til slutt fjerner oppføringen. En inaktiv oppføring utløper, og en innkommende pakke fra den fjerne siden blir da forkastet av gatewayen før den når verten. En tunnel som virket hele formiddagen slutter å svare om ettermiddagen nettopp av denne grunnen.
Dette er en andre og uavhengig mekanisme som gir det samme retningsbestemte symptomet. Både kunnskapen om endepunktet og oversettelsestilstanden må være riktig, og å rette den ene retter ikke den andre.
Konfigurer retningen du faktisk vil ha
For en klient som må starte forbindelsen, sett serverens endepunkt i klientens part-seksjon og la det bli der. Å stole på at serveren sender først er å stole på et tilfelle i trafikkrekkefølgen som vil endre seg på et stille nettverk. Konfigurasjonen bør oppgi den tiltenkte retningen, ikke oppdage den.
For en part bak oversettelse som må forbli tilgjengelig, aktiver en vedvarende keepalive på den siden. En keepalive hvert 25 sekund er den vanlige startverdien, og formålet er å holde oppføringen åpen fremfor å teste tunnelen. Velg én side til å bære den, for aktivering på begge sider dobler trafikken og loggstøyen uten å forbedre resultatet.
Sammenlign tilstanden før og etter utløseren
Ta de to visningene i øyeblikket det feiler, og deretter igjen etter at serveren sender. Den første kommandoen viser endepunkter og alderen på håndtrykket. Den andre viser om det finnes en oversettelsesoppføring for porten. Opptaket viser hvilken retning som faktisk gikk over ledningen, og rutejekken bekrefter at klienten ikke sender den trafikken et helt annet sted.
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
Noter endepunktkolonnen og oversettelsesoppføringen sammen. En part uten endepunkt og en gateway uten oppføring er to forskjellige feil. Bare én av dem rettes av en keepalive.