Het openbare IP is veranderd en de VPN geeft geen verkeer meer door

Een herverbinding bij de provider of een wijziging in de vertaling stroomopwaarts verandert de openbare bron van een VPN-sessie, terwijl het lokale privéadres van de client meestal precies blijft zoals het was. De tunnel lijkt dan verbonden terwijl er niets nuttigs doorheen gaat. Beide waarnemingen zijn tegelijk waar, en juist dat maakt het rapport verwarrend.

Werk de vier controles op volgorde af en stop bij de eerste die mislukt.

Welk adres is werkelijk veranderd

Vergelijk de toestand van de lokale interface met de bron die een extern eindpunt ziet, op een punt waar u bevoegd bent om te kijken. Een nieuw openbaar adres betekent niet een nieuwe lokale gateway, en een wijziging van de lokale interface garandeert ook niet dat de openbare bron is verschoven. De vertaling ertussen betekent dat het twee onafhankelijke feiten zijn. Noteer het exacte pad en het tijdstip waarop u het hebt waargenomen, want een geolocatielabel dat uit een oud rapport is gekopieerd, beantwoordt een andere vraag.

Vraag specifiek of de buitenste bron is veranderd, het binnenste tunneladres, of beide. Alleen het eerste verklaart een peer die blijft sturen naar een pad dat niet meer bestaat.

Laat het protocol de verplaatsing afhandelen

Protocollen verschillen in hoe ze leren dat een peer is verplaatst, en dat verschil is van belang voor de vraag of u überhaupt moet ingrijpen. WireGuard werkt het eindpunt van een peer bij wanneer het een pakket ontvangt dat met de sleutel van die peer wordt geauthenticeerd, waardoor een adreswijziging zonder enige configuratie kan worden opgevangen. IKEv2 heeft MOBIKE voor hetzelfde doel waar beide uiteinden het ondersteunen. Oudere ontwerpen herstellen door de tunnel opnieuw op te bouwen.

Wat u niet moet doen, is een niet-geauthenticeerd bericht accepteren als bewijs dat de identiteit van een peer is verschoven. Het is triviaal om een datagram te vervalsen dat een nieuw adres beweert, en een client die gelooft dat hij naar het eindpunt van een aanvaller kan worden gestuurd. Het geauthenticeerde protocol is het mechanisme; een melding is dat niet.

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

Wis de verouderde buitenste binding

Wanneer het protocol roaming wel ondersteunt en verkeer toch faalt, is het obstakel vaak toestandhoudende apparatuur onderweg of een beleid aan de verre kant. Een firewall die de oude stroom volgde, kan de verouderde vermelding houden, en een toegangsregel aan de serverkant die aan de oude bron is gekoppeld, laat de nieuwe stilzwijgend vallen. De mapping opschonen en de regel opnieuw controleren is sneller dan inloggegevens vervangen.

Houd de vereiste blokkering in stand terwijl u onderzoek doet. Het beleid wijd openzetten om te testen of de tunnel herstelt, leert u niets over de oorzaak en laat de uitrol slechter achter dan u hem aantrof.

Test opnieuw met een nieuw verzoek

Een applicatiesessie die vóór de wijziging is opgezet, overleeft het niet, omdat de vier-tupel waarop hij was gebouwd niet meer bestaat. Genereer na het herstel een nieuw verzoek en bevestig dat het voltooit, in plaats van te kijken hoe een oude download op nul blijft staan en te concluderen dat de tunnel nog steeds stuk is. Juist dat ene onderscheid lost een groot deel van deze rapporten op.

Noteer daarna beide helften van de diagnose: wat stroomopwaarts is veranderd en welke ondersteunde herstelstap de stroom heeft hersteld. De volgende keer gaat sneller, en de notitie is wat het sneller maakt.

Als een nieuw verzoek slaagt en het oude nooit wordt hervat, is de tunnel gerepareerd en hoeft de applicatie alleen opnieuw verbinding te maken.