En genopkobling hos udbyderen eller en ændring i oversættelsen længere oppe ændrer den offentlige kilde for en VPN-session, mens klientens lokale private adresse normalt bliver præcis, som den var. Tunnelen ser så forbundet ud, mens der ikke passerer noget brugbart igennem den. Begge observationer er sande på samme tid, og det er præcis det, der gør rapporten forvirrende.

Gå gennem de fire kontroller i rækkefølge, og stop ved den første, der fejler.

Hvilken adresse ændrede sig egentlig

Sammenlign den lokale interfaces tilstand med den kilde, et fjernendepunkt ser, på et tidspunkt, hvor du har tilladelse til at kigge. En ny offentlig adresse betyder ikke en ny lokal gateway, og en ændring af det lokale interface garanterer heller ikke, at den offentlige kilde er flyttet. Oversættelse ind i mellem betyder, at de to er uafhængige fakta. Notér den præcise vej og det tidspunkt, hvor du observerede den, fordi et geolokaliseringsmærke kopieret fra en gammel rapport besvarer et andet spørgsmål.

Spørg specifikt, om den ydre kilde ændrede sig, om den indre tunneladresse ændrede sig, eller begge. Kun det første forklarer en peer, der fortsat sender til en vej, som ikke længere findes.

Lad protokollen håndtere flytningen

Protokoller er forskellige i, hvordan de lærer, at en peer er flyttet, og forskellen betyder noget for, om du overhovedet bør gribe ind. WireGuard opdaterer en peers endepunkt, når den modtager en pakke, der autentificeres med den pågældende peers nøgle, og derfor kan en adresseændring optages uden nogen konfiguration. IKEv2 har MOBIKE til samme formål, hvor begge ender understøtter det. Ældre designs kommer sig ved at genopbygge tunnelen i stedet.

Det, du ikke bør gøre, er at acceptere en uautentificeret besked som bevis på, at en peers identitet er flyttet. Det er trivielt at forfalske et datagram, der påstår en ny adresse, og en klient, der tror, at den kan styres til angriberens endepunkt. Den autentificerede protokol er mekanismen; en notifikation er det ikke.

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

Ryd den forældede ydre binding

Når protokollen understøtter roaming, og trafikken stadig fejler, er forhindringen ofte stateful udstyr i midten eller en politik i den fjerne ende. En firewall, der sporede den gamle strøm, kan beholde den forældede post, og en adgangsregel på serversiden bundet til den gamle kilde vil droppe den nye i stilhed. At rydde mappingen og tjekke reglen igen er hurtigere end at udskifte legitimationsoplysninger.

Hold den nødvendige blokering i kraft, mens du undersøger. At åbne politikken på vid gab for at teste, om tunnelen kommer sig, lærer dig intet om årsagen og efterlader opsætningen værre, end du fandt den.

Test igen med en ny anmodning

En applikationssession, der blev etableret før ændringen, overlever den ikke, fordi den firedublet, den blev bygget på, ikke længere findes. Generér en ny anmodning efter genoprettelsen, og bekræft, at den fuldføres, i stedet for at se en gammel download stå på nul og konkludere, at tunnelen stadig er i stykker. Den ene forskel forklarer en stor del af disse rapporter.

Notér derefter begge halvdele af diagnosen: hvad ændrede sig længere oppe, og hvilket understøttet genopretningstrin der genskabte strømmen. Den næste forekomst bliver hurtigere, og noten er det, der gør den hurtigere.

Hvis en ny anmodning lykkes, og den gamle aldrig genoptages, blev tunnelen rettet, og applikationen skal blot genopkoble.

Relaterede artikler