WAN-IP is veranderd en de tunnel viel weg: de controles op volgorde

De tunnel valt weg, de router logt een herverbinding, en niets op de LAN is bewogen. Een nieuw WAN-adres maakt de buitenverbinding ongeldig zonder binnen iets te veranderen: het bronadres van de client is veranderd, de oude NAT-status wijst naar een bron die niet meer bestaat, en de externe peer stuurt mogelijk nog naar het vorige adres. Herstel is normaal gedrag, en de nuttige vraag is welke status niet is bijgewerkt.

Benoem de gebeurtenis voordat u het log leest

Controleer wat er werkelijk op de toegangslaag is gebeurd. Een vernieuwing van de ISP-lease is één gebeurtenis. Een PPPoE-sessie die opnieuw is verbonden is een andere. Een herstart modem, of een WAN-failover van de ene uplink naar de andere, verandert het buitenadres of het pad daarvan op een derde manier. Het zijn niet dezelfde gebeurtenissen en ze laten niet hetzelfde residu achter.

Een herverbindingsregel in het VPN-log is ook geen bewijs van een WAN-wijziging. Een idle-timeout, een herauthenticatie-interval en dead-peer-detectie produceren allemaal herverbindingen zonder enige adreswijziging. Vergelijk tijdstempels uit het toegangslog met het VPN-log voordat u iets concludeert, en houd het vergelijkingsvenster breed genoeg om een wijziging te vangen die 's nachts is gebeurd.

Roaming en herverbinden zijn verschillende protocollen

WireGuard heeft geauthenticeerde roaming in het protocol ingebouwd: wanneer een peer een correct geauthenticeerd pakket van een nieuw bronadres ontvangt, werkt hij het eindpunt van die peer bij. De WireGuard-snelstart beschrijft de peer-configuratie die dit mogelijk maakt, en daarom herstelt een client op een wisselend adres vaak zonder zichtbare herstart.

OpenVPN gedraagt zich standaard anders. Een UDP-sessie kan eindigen en opnieuw verbinden, en het optionele float-gedrag laat een geauthenticeerde peer doorgaan vanaf een nieuw adres waar de configuratie dat toestaat. TCP-tunnels zijn strenger, omdat de verbinding zelf aan het adrespaar is gebonden. Dat verschil bepaalt of het herstel onzichtbaar lijkt of zich elke keer in het log meldt.

Geen van beide gedragingen zegt iets over de toepassingen binnenin. Een herstelde tunnel herstelt geen TCP-sessie die de peer al als dood beschouwde.

Status die de tunnel niet bezit

Vertaal- en routeringsstatus overleeft de herverbinding op manieren die mensen verrassen. Een conntrack-vermelding die voor de oude bron is aangemaakt, houdt het antwoordpad verankerd aan een adres dat niet meer bestaat, en die verloopt volgens zijn eigen schema, niet wanneer de tunnel terugkwam. De tunneldienst herstarten verkort die wachttijd niet, dus een gerepareerde verbinding kan er nog een tijdje kapot uitzien.

Routes en beleidsregels kunnen naar de oude gateway of interface verwijzen. Een regelset die voor een WAN-wissel correct was, kan naar een apparaat wijzen dat nu plat ligt, wat een tunnel oplevert die zich als verbonden meldt en verkeer dat nergens heen gaat. Dynamische DNS voor een server die u host is een apart probleem van een client die een nieuwe bron krijgt. De vermelding moet worden bijgewerkt zodat externe clients u vinden, en geen configuratie aan de clientkant compenseert een adres dat de vertaling stroomopwaarts niet doorgeeft.

Orden de controles van buiten naar binnen

De volgorde hieronder loopt van de buitenverbinding naar binnen, en stoppen bij de eerste stap die mislukt is wat het nuttig maakt: elke controle sluit de laag erboven uit. Houd die volgorde aan, ook wanneer de fout voor de hand ligt.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Het eerste commando toont het huidige eindpunt en de leeftijd van de handshake voor elke peer. De tweede en derde tonen of de buiteninterface en de route naar het eindpunt nog zin hebben. De conntrack-telling is een grove controle voor status die van het vorige adres overblijft, en het journaal is de plek waar de reden van de herverbinding wordt vastgelegd.

Test daarna vanaf een LAN-client in plaats van vanaf de router. Een ping die door de router zelf is verstuurd gebruikt een ander pad dan doorgestuurd verkeer, dus een geslaagde ping vanaf de router bewijst dat de tunnel bestaat en niets over de bereikbaarheid van de client.

Bepaal het verwachte gedrag en schrijf het op

Opnieuw verbinden is correct gedrag voor de meeste implementaties, dus het doel is niet om dat te voorkomen. Bepaal in plaats daarvan wat er met het verkeer moet gebeuren tijdens de onderbreking: stoppen, vasthouden of overschakelen naar een ander pad. Die beslissing hoort bij de firewall en het routeringsbeleid, niet bij het VPN-profiel.

Leg de toegangsgebeurtenissen en de herverbindingstijden samen een week vast. Herhaalde wijzigingen zonder overeenkomstige toegangsgebeurtenis wijzen op de toegangsdienst, en het vervangen van het VPN-profiel lost geen uplink op die steeds opnieuw onderhandelt. Eén paar vermeldingen in dezelfde minuut beslecht de vraag voor dat incident en geeft het volgende een basislijn.