Den offentliga IP-adressen ändrades och VPN slutade föra trafik

En återanslutning hos leverantören eller en ändring i översättningen längre upp ändrar den offentliga källan för en VPN-session, medan klientens lokala privata adress vanligtvis blir exakt som den var. Tunneln ser då ansluten ut medan ingenting användbart passerar genom den. Båda observationerna är sanna samtidigt, och det är just det som gör rapporten förvirrande.

Gå igenom de fyra kontrollerna i ordning och stanna vid den första som misslyckas.

Vilken adress ändrades egentligen

Jämför det lokala gränssnittets tillstånd med den källa som en avlägsen ändpunkt ser, vid en punkt där du har tillstånd att titta. En ny offentlig adress betyder inte en ny lokal gateway, och en ändring av det lokala gränssnittet garanterar inte heller att den offentliga källan har flyttat. Översättningen däremellan betyder att det är två oberoende fakta. Anteckna den exakta vägen och tiden då du observerade den, eftersom en geolokaliseringsetikett kopierad från en gammal rapport besvarar en annan fråga.

Fråga specifikt om den yttre källan ändrades, den inre tunneladressen ändrades, eller båda. Bara det första förklarar en peer som fortsätter skicka till en väg som inte längre finns.

Låt protokollet hantera flytten

Protokoll skiljer sig i hur de får veta att en peer har flyttat, och skillnaden spelar roll för om du alls bör ingripa. WireGuard uppdaterar en peers ändpunkt när den tar emot ett paket som autentiseras med den peers nyckel, och därför kan en adressändring absorberas utan någon konfiguration. IKEv2 har MOBIKE för samma ändamål där båda ändar stöder det. Äldre konstruktioner återhämtar sig genom att bygga om tunneln i stället.

Det du inte bör göra är att acceptera ett oautentiserat meddelande som bevis för att en peers identitet har flyttat. Det är trivialt att förfalska ett datagram som påstår en ny adress, och en klient som tror att den kan styras till angriparens ändpunkt. Det autentiserade protokollet är mekanismen; en avisering är det inte.

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

Rensa den föråldrade yttre bindningen

När protokollet stöder roaming och trafiken ändå misslyckas, är hindret ofta utrustning med tillstånd i mitten eller en policy i den bortre änden. En brandvägg som spårade det gamla flödet kan behålla den föråldrade posten, och en åtkomstregel på serversidan kopplad till den gamla källan kommer tyst att släppa den nya. Att rensa mappningen och kontrollera regeln igen är snabbare än att byta autentiseringsuppgifter.

Håll den nödvändiga blockeringen i kraft medan du undersöker. Att öppna policyn på vid gavel för att testa om tunneln återhämtar sig lär dig ingenting om orsaken och lämnar driftsättningen sämre än du fann den.

Testa igen med en ny begäran

En applikationssession som upprättades före ändringen överlever den inte, eftersom den fyrtupel den byggdes på inte längre finns. Generera en ny begäran efter återhämtningen och bekräfta att den fullbordas, i stället för att se en gammal nedladdning stå på noll och dra slutsatsen att tunneln fortfarande är trasig. Just den enda skillnaden löser en stor del av dessa rapporter.

Anteckna sedan båda halvorna av diagnosen: vad som ändrades längre upp och vilket stött återhämtningssteg som återställde flödet. Nästa gång går snabbare, och anteckningen är det som gör den snabbare.

Om en ny begäran lyckas och den gamla aldrig återupptas, reparerades tunneln och applikationen behöver bara ansluta igen.