Den offentlige IP-adressen endret seg, og VPN sluttet å føre trafikk

En ny tilkobling hos leverandøren eller en endring i oversettelsen lenger opp endrer den offentlige kilden for en VPN-økt, mens klientens lokale private adresse vanligvis blir nøyaktig som den var. Tunnelen ser da tilkoblet ut mens ingenting nyttig går gjennom den. Begge observasjonene er sanne samtidig, og det er nettopp derfor rapporten er forvirrende.

Gå gjennom de fire kontrollene i rekkefølge, og stopp ved den første som feiler.

Hvilken adresse endret seg egentlig

Sammenlign tilstanden til det lokale grensesnittet med kilden en ekstern endepunkt ser, på et punkt der du har tillatelse til å se. En ny offentlig adresse betyr ikke en ny lokal gateway, og en endring i det lokale grensesnittet garanterer heller ikke at den offentlige kilden har flyttet seg. Oversettelsen imellom betyr at de to er uavhengige fakta. Noter den nøyaktige veien og tidspunktet du observerte den, fordi en geolokasjonsetikett kopiert fra en gammel rapport svarer på et annet spørsmål.

Spør spesifikt om den ytre kilden endret seg, den indre tunneladressen endret seg, eller begge. Bare det første forklarer en peer som fortsatt sender til en vei som ikke lenger finnes.

La protokollen håndtere flyttingen

Protokoller er forskjellige i hvordan de lærer at en peer har flyttet seg, og forskjellen betyr noe for om du i det hele tatt bør gripe inn. WireGuard oppdaterer endepunktet til en peer når den mottar en pakke som autentiseres med den peerens nøkkel, og derfor kan en adresseendring absorberes uten noen konfigurasjon. IKEv2 har MOBIKE for samme formål der begge ender støtter det. Eldre design kommer seg ved å bygge tunnelen på nytt i stedet.

Det du ikke bør gjøre, er å godta en uautentisert melding som bevis på at identiteten til en peer har flyttet seg. Det er trivielt å forfalske et datagram som hevder en ny adresse, og en klient som tror at den kan styres til angriperens endepunkt. Den autentiserte protokollen er mekanismen; en varsling er det ikke.

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

Fjern den foreldede ytre bindingen

Når protokollen støtter roaming og trafikken likevel feiler, er hindringen ofte utstyr med tilstand i midten eller en policy i den fjerne enden. En brannmur som sporet den gamle strømmen kan beholde den foreldede oppføringen, og en tilgangsregel på serversiden knyttet til den gamle kilden vil droppe den nye i stillhet. Å rydde mapperingen og sjekke regelen på nytt er raskere enn å bytte legitimasjon.

Hold den nødvendige blokkeringen i kraft mens du undersøker. Å åpne policyen på vidt gap for å teste om tunnelen kommer seg, lærer deg ingenting om årsaken og etterlater utrullingen verre enn du fant den.

Test på nytt med en ny forespørsel

En applikasjonsøkt som ble etablert før endringen, overlever den ikke, fordi firedoblingen den ble bygget på ikke lenger finnes. Generer en ny forespørsel etter gjenopprettingen og bekreft at den fullføres, i stedet for å se en gammel nedlasting stå på null og konkludere med at tunnelen fortsatt er ødelagt. Den ene forskjellen forklarer en stor del av disse rapportene.

Noter deretter begge halvdelene av diagnosen: hva som endret seg lenger opp, og hvilket støttet gjenopprettingstrinn som gjenopprettet strømmen. Neste gang blir raskere, og notatet er det som gjør den raskere.

Hvis en ny forespørsel lykkes og den gamle aldri gjenopptas, ble tunnelen reparert, og applikasjonen trenger bare å koble til på nytt.