Tunnelen kjem opp på mobildata og blir deretter ståande på koplar til heime, med same profil, same peer-nøkkel og inga konfigurasjonsendring imellom. Skilnaden ligg i reisa: ei førespurnad frå innsida av LAN-et til den offentlege adressa til rutaren er ikkje same reise som ei førespurnad som kjem frå internett. Dei fleste heimegatewayar implementerer ikkje returvegen i det heile, eller berre for visse protokollar. Det får symptomet til å sjå ut som ein øydelagd nøkkel medan ingenting ved nøkkelen har flytta seg. Fastslå kva veg som feila før du rører ein nøkkel, ei portvideresending eller ein klientprofil.

Éi adresse, to forskjellige vegar

Utanfrå når ei pakke den offentlege adressa til rutaren, og ei portvideresendingsregel gjev henne vidare til WireGuard-lyttaren på den interne verten. Innanfrå ringjer klienten same offentlege adresse, så pakka forlèt klienten, kjem til rutaren og må snuast tilbake mot LAN-et. Det er ved denne tilbakesnuvinga dei to vegane skil lag, fordi rutaren må omsetje ein straum som både forlèt og kjem inn att på same grensesnitt. Mange implementasjonar slepp han i staden for å omsetje han, og klienten ventar då på eit handtrykk som aldri vart sendt.

Åtferda blir vanlegvis kalla NAT-loopback eller hairpinning, og ho høyrer til rutaren snarare enn til WireGuard; RFC 4787 skildrar omsetjingstilfella der ein gateway kan eller ikkje kan støtte henne. WireGuard sjølv har inga meining om vegen, fordi han berre ser pakker som når grensesnittet. Når rutaren slepp straumen, mottek daemonen aldri noko, klienten rapporterer tidsavbrot på handtrykket, og serverloggen blir ståande tom. Ein tom logg er derfor eit spor om kvar pakka stoppa, ikkje prov for at serveren er nede. Det er også grunnen til at ein nyinstallasjon ikkje endrar noko.

Det motsette tel òg: ein serverlogg som viser eit handtrykksforsøk frå LAN-adressa, provar at pakka kom fram og at vegen er i orden, noko som flyttar undersøkinga til nøklar og tillatne adresser. Les loggen for det han provar, ikkje for det du håpte å sjå.

Reproduser det før du endrar noko

Test frå eit autorisert eksternt nettverk med same eining og same profil, og gjenta testen deretter inne i LAN-et utan å endre noko. Eit fullført handtrykk ute og ein klient som inne aldri forlèt eininga, reproduserer tilstanden i staden for å gjette på han. Begge forsøka må bruke same profil, elles provar samanlikninga ingenting.

Sjå deretter på kva endepunktnamnet løyser ut til for denne eininga. Dei tre følgjande kommandoane viser òg kva adresse klienten faktisk ringde:

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

Den første kommandoen rapporterer endepunktet grensesnittet brukar akkurat no, og dei to andre viser kva namnet løyser ut til på denne maskina. Ein klient som ringjer ei offentleg adresse medan han sit på same nettverk som serveren, brukar hairpin-vegen. Ein klient som ringjer LAN-adressa gjer det ikkje, og ein feil der høyrer til ei anna undersøking. Den skilnaden avgjer om neste avsnitt gjeld i det heile.

Støtta måtar å nå ein nær server

Den reinaste ordninga er eit split-horizon-svar: det offentlege namnet løyser ut til den offentlege adressa for internett og til LAN-adressa til serveren for klientar innanfor. Profilen held eitt endepunktnamn, og resolveren vel vegen. Det krev kontroll over det interne DNS-svaret, som ein heimerutar vanlegvis tilbyr og ein organisasjon kan ordne medvite. Utan den kontrollen står vala mellom ein ruterfunksjon eller ein andre profil.

Ruterfunksjonen er refleksjon: gatewayen omset straumen frå innsida til utsida og sender han tilbake inn. Der han verkar, trengst inga klientendring, og der han ikkje verkar, reddar inga klientinnstilling han. Test han ved å følgje med på serverloggen under eit internt forsøk i staden for å lese funksjonslista til rutaren.

Å endre profilen til ei privat adresse er ein diagnose, ikkje eit design. Det provar at serveren svarar på LAN-et, og det øydelegg same profil i det augeblikket laptoppen forlèt huset.

ApproachWhat it depends onWhere it fails
Split-horizon nameControl of the internal DNS answerClients that resolve through a server outside the zone
Router reflectionGateway support for hairpin translationRouters that drop the flow silently
Private address in the profileNothing beyond the LANEvery network except the one at home

Hald profilen brukbar borte frå heimen

Kva veg du enn vel, lat identitetskontrollen vere i fred. Endepunktadressa er ikkje peer-identiteten, og ei adresseendring rettferdiggjer aldri å godta ein urelatert offentleg nøkkel som tilfeldigvis svarar. WireGuard autentiserer med nøkkelen, så ein feil vert feilar handtrykket i staden for å gje tilgang til noko uventa.

Viss den offentlege adressa flyttar seg, er dynamisk DNS det som held namnet nyttig, og oppdateringsåtferda til klienten avgjer kor raskt endringa slår inn. Test det utanfrå etter ei adresseendring, fordi LAN-tilfellet ikkje kan stadfeste det. Sjå opp for ein resolver som cachar det gamle svaret utover levetida til posten. Eit namn som framleis peikar på den førre adressa, ser nøyaktig ut som ein server som gjekk ned.

Skriv ned kva namn profilen brukar og kva det løyser ut til på kvar side av grensa. Ein profil som avheng av ein ruterfunksjon ingen har notert, er ei supporthenvending som ventar på neste fastvareoppdatering. Notatet er òg det som fortel neste person om ein intern feil er det kjende hairpin-tilfellet eller noko nytt.

Relaterte artiklar