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

Tunnelen kommer op på mobildata og bliver derefter stående på forbinder hjemme, med samme profil, samme peer-nøgle og ingen konfigurationsændring imellem. Forskellen ligger i rejsen: en anmodning fra indersiden af LAN’et til routerens offentlige adresse er ikke samme rejse som en anmodning, der kommer fra internettet. De fleste hjemmegateways implementerer ikke returvejen overhovedet eller kun for bestemte protokoller. Det får symptomet til at se ud som en ødelagt nøgle, mens intet ved nøglen har flyttet sig. Fastslå, hvilken vej der fejlede, før du rører en nøgle, en portvideresendelse eller en klientprofil.

Én adresse, to forskellige veje

Udefra når en pakke routerens offentlige adresse, og en portvideresendelsesregel giver den videre til WireGuard-lytteren på den interne vært. Indefra ringer klienten samme offentlige adresse, så pakken forlader klienten, ankommer til routeren og skal vendes tilbage mod LAN’et. Det er ved denne tilbagevending, de to veje skilles, fordi routeren skal oversætte en strøm, som både forlader og kommer ind igen på samme interface. Mange implementeringer dropper den i stedet for at oversætte den, og klienten venter derefter på et håndtryk, der aldrig blev sendt.

Adfærden kaldes normalt NAT-loopback eller hairpinning, og den hører til routeren snarere end til WireGuard; RFC 4787 beskriver de oversættelsestilfælde, hvor en gateway kan eller ikke kan understøtte den. WireGuard selv har ingen mening om vejen, fordi den kun ser pakker, der når dens interface. Når routeren dropper strømmen, modtager daemonen aldrig noget, klienten rapporterer timeout på håndtrykket, og serverloggen forbliver tom. En tom log er derfor et spor om, hvor pakken stoppede, ikke bevis for at serveren er nede. Det er også grunden til, at en geninstallation ikke ændrer noget.

Det omvendte tæller også: en serverlog, der viser et håndtryksforsøg fra LAN-adressen, beviser, at pakken ankom, og at vejen er i orden, hvilket flytter undersøgelsen til nøgler og tilladte adresser. Læs loggen for det, den beviser, ikke for det, du håbede at se.

Reproducér det, før du ændrer noget

Test fra et autoriseret eksternt netværk med samme enhed og samme profil, og gentag derefter testen inde i LAN’et uden at ændre noget. Et fuldført håndtryk ude og en klient, der inde aldrig forlader enheden, reproducerer tilstanden i stedet for at gætte på den. Begge forsøg skal bruge samme profil, ellers beviser sammenligningen intet.

Se derefter på, hvad endepunktnavnet opløser til for denne enhed. De tre følgende kommandoer viser også, hvilken adresse klienten faktisk ringede til:

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

Den første kommando rapporterer det endepunkt, interfacet bruger lige nu, og de to andre viser, hvad navnet opløser til på denne maskine. En klient, der ringer en offentlig adresse, mens den sidder på samme netværk som serveren, bruger hairpin-vejen. En klient, der ringer LAN-adressen, gør det ikke, og en fejl der hører til en anden undersøgelse. Den forskel afgør, om næste afsnit overhovedet gælder.

Understøttede måder at nå en nær server

Den reneste ordning er et split-horizon-svar: det offentlige navn opløser til den offentlige adresse for internettet og til serverens LAN-adresse for klienter indenfor. Profilen beholder ét endepunktnavn, og resolveren vælger vejen. Det kræver kontrol over det interne DNS-svar, som en hjemmerouter normalt tilbyder, og som en organisation kan arrangere bevidst. Uden den kontrol står valget mellem en routerfunktion eller en anden profil.

Routerfunktionen er refleksion: gatewayen oversætter strømmen fra indersiden til ydersiden og sender den tilbage ind. Hvor den virker, kræves ingen klientændring, og hvor den ikke virker, redder ingen klientindstilling den. Test den ved at følge med i serverloggen under et internt forsøg i stedet for at læse routerens funktionsliste.

At ændre profilen til en privat adresse er en diagnose, ikke et design. Det beviser, at serveren svarer på LAN’et, og det ødelægger samme profil i det øjeblik, laptops forlader huset.

Hold profilen brugbar uden for hjemmet

Uanset hvilken vej du vælger, lad identitetskontrollen være i fred. Endepunktadressen er ikke peer-identiteten, og en adresseændring retfærdiggør aldrig at acceptere en urelateret offentlig nøgle, der tilfældigvis svarer. WireGuard autentificerer med nøglen, så en forkert vært fejler håndtrykket i stedet for at give adgang til noget uventet.

Hvis den offentlige adresse flytter sig, er dynamisk DNS det, der holder navnet brugbart, og klientens opdateringsadfærd afgør, hvor hurtigt ændringen slår igennem. Test det udefra efter en adresseændring, fordi LAN-tilfældet ikke kan bekræfte det. Vær opmærksom på en resolver, der cacher det gamle svar ud over postens levetid. Et navn, der stadig peger på den forrige adresse, ser præcis ud som en server, der gik ned.

Skriv ned, hvilket navn profilen bruger, og hvad det opløser til på hver side af grænsen. En profil, der afhænger af en routerfunktion, ingen har noteret, er en supporthenvendelse, der venter på den næste firmwareopdatering. Noten er også det, der fortæller den næste person, om en intern fejl er det kendte hairpin-tilfælde eller noget nyt.