WireGuard virker på mobildata, men ikke på samme wifi

Tunnelen kommer opp på mobildata og blir deretter stående på kobler til hjemme, med samme profil, samme peer-nøkkel og ingen konfigurasjonsendring imellom. Forskjellen ligger i reisen: en forespørsel fra innsiden av LAN-et til den offentlige adressen til ruteren er ikke samme reise som en forespørsel som kommer fra internett. De fleste hjemmegatewayer implementerer ikke returveien i det hele tatt, eller bare for visse protokoller. Det får symptomet til å se ut som en ødelagt nøkkel mens ingenting ved nøkkelen har flyttet seg. Fastslå hvilken vei som feilet før du rører en nøkkel, en portvideresending eller en klientprofil.

Én adresse, to forskjellige veier

Utenfra når en pakke den offentlige adressen til ruteren, og en portvideresendingsregel gir den videre til WireGuard-lytteren på den interne verten. Innenfra ringer klienten samme offentlige adresse, så pakken forlater klienten, kommer til ruteren og må snus tilbake mot LAN-et. Det er ved denne tilbakesnuingen de to veiene skiller lag, fordi ruteren må oversette en strøm som både forlater og kommer inn igjen på samme grensesnitt. Mange implementasjoner slipper den i stedet for å oversette den, og klienten venter da på et håndtrykk som aldri ble sendt.

Atferden kalles vanligvis NAT-loopback eller hairpinning, og den hører til ruteren snarere enn til WireGuard; RFC 4787 beskriver oversettelsestilfellene der en gateway kan eller ikke kan støtte den. WireGuard selv har ingen mening om veien, fordi den bare ser pakker som når grensesnittet. Når ruteren slipper strømmen, mottar daemonen aldri noe, klienten rapporterer tidsavbrudd på håndtrykket, og serverloggen blir stående tom. En tom logg er derfor et spor om hvor pakken stoppet, ikke bevis for at serveren er nede. Det er også grunnen til at en nyinstallasjon ikke endrer noe.

Det motsatte teller også: en serverlogg som viser et håndtrykksforsøk fra LAN-adressen, beviser at pakken kom frem og at veien er i orden, noe som flytter undersøkelsen til nøkler og tillatte adresser. Les loggen for det den beviser, ikke for det du håpet å se.

Reproduser det før du endrer noe

Test fra et autorisert eksternt nettverk med samme enhet og samme profil, og gjenta testen deretter inne i LAN-et uten å endre noe. Et fullført håndtrykk ute og en klient som inne aldri forlater enheten, reproduserer tilstanden i stedet for å gjette på den. Begge forsøkene må bruke samme profil, ellers beviser sammenligningen ingenting.

Se deretter på hva endepunktnavnet løser ut til for denne enheten. De tre følgende kommandoene viser også hvilken adresse klienten faktisk ringte:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Den første kommandoen rapporterer endepunktet grensesnittet bruker akkurat nå, og de to andre viser hva navnet løser ut til på denne maskinen. En klient som ringer en offentlig adresse mens den sitter på samme nettverk som serveren, bruker hairpin-veien. En klient som ringer LAN-adressen gjør det ikke, og en feil der hører til en annen undersøkelse. Den forskjellen avgjør om neste avsnitt gjelder i det hele tatt.

Støttede måter å nå en nær server

Den reneste ordningen er et split-horizon-svar: det offentlige navnet løser ut til den offentlige adressen for internett og til serverens LAN-adresse for klienter innenfor. Profilen beholder ett endepunktnavn, og resolveren velger veien. Det krever kontroll over det interne DNS-svaret, som en hjemmeruter vanligvis tilbyr og en organisasjon kan ordne bevisst. Uten den kontrollen står valgene mellom en ruterfunksjon eller en andre profil.

Ruterfunksjonen er refleksjon: gatewayen oversetter strømmen fra innsiden til utsiden og sender den tilbake inn. Der den virker, trengs ingen klientendring, og der den ikke virker, redder ingen klientinnstilling den. Test den ved å følge med på serverloggen under et internt forsøk i stedet for å lese ruterens funksjonsliste.

Å endre profilen til en privat adresse er en diagnose, ikke en design. Det beviser at serveren svarer på LAN-et, og det ødelegger samme profil i det øyeblikket laptopen forlater huset.

Hold profilen brukbar borte fra hjemmet

Uansett hvilken vei du velger, la identitetskontrollen være i fred. Endepunktadressen er ikke peer-identiteten, og en adresseendring rettferdiggjør aldri å akseptere en urelatert offentlig nøkkel som tilfeldigvis svarer. WireGuard autentiserer med nøkkelen, så en feil vert feiler håndtrykket i stedet for å gi tilgang til noe uventet.

Hvis den offentlige adressen flytter seg, er dynamisk DNS det som holder navnet nyttig, og klientens oppdateringsatferd avgjør hvor raskt endringen slår inn. Test det utenfra etter en adresseendring, fordi LAN-tilfellet ikke kan bekrefte det. Se opp for en resolver som cacher det gamle svaret utover postens levetid. Et navn som fortsatt peker på den forrige adressen, ser nøyaktig ut som en server som gikk ned.

Skriv ned hvilket navn profilen bruker og hva det løser ut til på hver side av grensen. En profil som avhenger av en ruterfunksjon ingen har notert, er en supporthenvendelse som venter på neste fastvareoppdatering. Notatet er også det som forteller neste person om en intern feil er det kjente hairpin-tilfellet eller noe nytt.