Van VPN-provider wisselen: plan de hostnaam, niet alleen het IP

Uw DNS-record is correct, de vervanging is gezond, en toch doen sommige clients er uren over om het oude adres te kiezen. Een paar mislukken meteen op een naam die wel wordt opgelost en nooit antwoordt. Beide uitkomsten komen uit één gat: een hostnaam verandert wat een client opzoekt, niet wanneer hij dat opzoekt, en ook niet waarop hij vertrouwt wanneer het antwoord binnenkomt.

Het symptoom: een correct record, verouderde tunnels

Een profiel dat een naam opslaat, is geen client die hem blijft opzoeken. De meeste lossen hem één keer op, bij het toepassen van de configuratie of wanneer de tunnel omhoog komt, en hergebruiken dat adres daarna tot de sessie eindigt. Een lange TTL daarbovenop is de reden dat de overstap rond herverbindingen moet worden gepland en niet rond de DNS-wijziging.

Geen van beide gedragingen is een defect, en dat maakt het symptoom juist verwarrend. De client werkt met een antwoord dat hij eerder kreeg, en niets aan de serverkant laat zien welk antwoord dat was. Plan de herverbinding in het onderhoudsvenster en vertel gebruikers wat ze zullen zien, of besteed het venster aan het beantwoorden van tickets. Een rij identieke meldingen is het gebruikelijke resultaat.

Wie de naam beheert, en wat de client verifieert

Controle over de zone bepaalt hoe snel een migratie kan verlopen. Houd het record bij een registrar waar u kunt inloggen, en schrijf op wie het anders kan wijzigen.

Vertrouwen volgt de naam niet. Een op TLS gebaseerde client kan een certificaatidentiteit of een vastgezette naam controleren, terwijl WireGuard de openbare sleutel van de peer authenticeert en de hostnaam volledig negeert. Dat verschil bepaalt of een DNS-wijziging genoeg is of dat elk profiel een nieuwe vingerafdruk nodig heeft. Een recordwijziging mag nooit een eindpunt autoriseren dat niemand heeft goedgekeurd.

Houd beheertoegang en hersteltoegang weg bij de openbare clientnaam. Een hostingaccount verliezen mag u niet ook het record kosten dat clients doorverwijst. Bewaar het herstelpad ergens dat niet afhangt van de provider die u verlaat.

Wanneer elke client de naam opnieuw leest

Het resolutiemoment is een eigenschap per client, dus controleer de implementatie die u werkelijk levert voordat u een overstapvenster belooft. wg-quick lost het eindpunt op wanneer de interface omhoog komt en houdt dat adres tot de tunnel opnieuw start. Een OpenVPN-client zoekt de naam op wanneer hij verbindt, en of hij bij herverbinding opnieuw kijkt hangt van zijn opties af.

Mobiele clients zijn de gebruikelijke verrassing, omdat ze een opgelost adres over slaap of een netwerkwissel kunnen vasthouden. Publiceer A- en AAAA-records alleen als de vervanging op beide families antwoordt. Een adres dat op één familie antwoordt, bewijst niets over de andere, en een dood AAAA-record voegt een time-out toe aan elke poging. Documenteer het resolutiegedrag voor elke client die u ondersteunt, en test dan op de apparaten die mensen echt gebruiken.

Een herverbinding is bij de meeste clients een gebruikersactie, en de server kan die niet afdwingen. Zet die stap in de onderhoudsnotitie, met een regel over wat de gebruiker zal zien wanneer het gebeurt.

Schakel over op bewijs en stel daarna het oude eindpunt buiten gebruik

Bewijs vóór de omschakeling elke laag op de vervanging: de listener antwoordt, de firewall laat de poort door, routes keren correct terug, de naam lost op naar het nieuwe adres en een bekende identiteit wordt geaccepteerd. Een listener die een verbinding aanneemt is niet hetzelfde als een die een handshake voltooit, dus test de handshake en niet de poort. Houd de actuele intrekkingslijst naast de configuratie, want een herstelde back-up maakt de peerlijst opnieuw zoals die was en zou toegang heropenen die u al had gesloten. Noteer met welke identiteit u hebt getest, want «het werkt» is geen bewijs dat iemand kan herhalen.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Tijdens de overgang houdt u verbindingspogingen op beide eindpunten voor dezelfde identiteit in de gaten. Een client die zich nog tegen het oude adres authenticeert, is een profiel of een gecacht antwoord dat nooit is verhuisd. Stel het oude eindpunt volgens een gedateerd plan buiten gebruik, want twee diensten die één identiteit accepteren laten twee deuren open.

De overstaptest is een applicatiesessie via het nieuwe eindpunt, geen ping. Zodra die sessie werkt en het oude eindpunt over een volledige herverbindingscyclus geen geautoriseerde pogingen logt, is de verhuizing klaar.