Den offentlege IP-adressa endra seg, og VPN slutta å føre trafikk

Ei ny tilkopling hos leverandøren eller ei endring i omsetjinga lenger opp endrar den offentlege kjelda for ein VPN-økt, medan den lokale private adressa til klienten vanlegvis blir nøyaktig som ho var. Tunnelen ser då tilkopla ut medan ingenting nyttig går gjennom han. Begge observasjonane er sanne samtidig, og det er nettopp derfor rapporten er forvirrande.

Gå gjennom dei fire kontrollane i rekkjefølgje, og stopp ved den første som feilar.

Kva adresse endra seg eigentleg

Samanlikn tilstanden til det lokale grensesnittet med kjelda ein ekstern endepunkt ser, på eit punkt der du har løyve til å sjå. Ei ny offentleg adresse tyder ikkje på ein ny lokal gateway, og ei endring i det lokale grensesnittet garanterer heller ikkje at den offentlege kjelda har flytta seg. Omsetjinga imellom tyder på at dei to er uavhengige fakta. Noter den nøyaktige vegen og tidspunktet du observerte han, fordi ei geolokasjonsetikett kopiert frå ein gammal rapport svarar på eit anna spørsmål.

Spør spesifikt om den ytre kjelda endra seg, den indre tunneladressa endra seg, eller begge. Berre det første forklarar ein peer som held fram med å senda til ein veg som ikkje lenger finst.

Lat protokollen handtere flyttinga

Protokollar er ulike i korleis dei lærer at ein peer har flytta seg, og skilnaden har noko å seia for om du i det heile bør gripe inn. WireGuard oppdaterer endepunktet til ein peer når han tek imot ein pakke som blir autentisert med nøkkelen til den peeren, og difor kan ei adresseendring bli teken opp utan noka konfigurasjon. IKEv2 har MOBIKE for same føremål der begge endar støttar det. Eldre design kjem seg ved å byggje tunnelen på nytt i staden.

Det du ikkje bør gjere, er å godta ei uautentisert melding som bevis på at identiteten til ein peer har flytta seg. Det er trivielt å forfalske eit datagram som hevdar ei ny adresse, og ein klient som trur at han kan styrast til endepunktet til angriparen. Den autentiserte protokollen er mekanismen; ei varsling er det ikkje.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Fjern den forelda ytre bindinga

Når protokollen støttar roaming og trafikken likevel feilar, er hindringa ofte utstyr med tilstand i midten eller ein policy i den fjerne enden. Ein brannmur som spora den gamle straumen kan behalde den forelda oppføringa, og ein tilgangsregel på serversida knytt til den gamle kjelda vil droppe den nye i det stille. Å rydde mapperinga og sjekke regelen på nytt er raskare enn å byte legitimasjon.

Hald den nødvendige blokkeringa i kraft medan du undersøkjer. Å opne policyen på vidt gap for å teste om tunnelen kjem seg, lærer deg ingenting om årsaka og lèt utrullinga verre etter seg enn du fann ho.

Test på nytt med ein ny førespurnad

Ein applikasjonsøkt som vart etablert før endringa, overlever henne ikkje, fordi firdoblinga ho vart bygd på ikkje lenger finst. Generer ein ny førespurnad etter gjenopprettinga og stadfest at han blir fullført, i staden for å sjå ein gammal nedlasting stå på null og slå fast at tunnelen framleis er øydelagd. Nettopp den eine skilnaden løyser ein stor del av desse rapportane.

Noter så begge halvdelane av diagnosen: kva som endra seg lenger opp, og kva støtta gjenopprettingstrinn som gav straumen tilbake. Neste gong går det raskare, og notatet er det som gjer det raskare.

Viss ein ny førespurnad lukkast og den gamle aldri blir teken opp att, vart tunnelen reparert, og applikasjonen treng berre å kople til på nytt.