Byt VPN-leverantör: planera värdnamnet, inte bara IP-adressen

Din DNS-post är korrekt, ersättaren är frisk, och ändå lägger vissa klienter timmar på att ringa den gamla adressen. Några misslyckas direkt mot ett namn som slås upp och aldrig svarar. Båda utfallen kommer från ett enda hål: ett värdnamn ändrar vad en klient slår upp, inte när den slår upp det, och inte vad den litar på när svaret kommer.

Symtomet: en korrekt post, föråldrade tunnlar

En profil som sparar ett namn är inte en klient som fortsätter slå upp det. De flesta slår upp det en gång, när konfigurationen tillämpas eller när tunneln kommer upp, och återanvänder sedan adressen till sessionen tar slut. En lång TTL ovanpå det är anledningen till att övergången måste planeras kring återanslutningar och inte kring DNS-redigeringen.

Inget av de två beteendena är en defekt, och det är just det som gör symtomet förvirrande. Klienten arbetar utifrån ett svar som den fick tidigare, och ingenting på serversidan visar vilket svar det var. Planera återanslutningen i underhållsfönstret och berätta för användarna vad de kommer att se, eller lägg fönstret på att svara på ärenden. En kö av identiska rapporter är det vanliga resultatet.

Vem som kontrollerar namnet, och vad klienten verifierar

Kontrollen över zonen avgör hur snabbt en migrering kan röra sig. Behåll posten hos en registrar du kan logga in hos, och skriv ned vem mer som kan ändra den.

Förtroende följer inte namnet. En TLS-baserad klient kan kontrollera en certifikatidentitet eller ett fäst namn, medan WireGuard autentiserar motpartens publika nyckel och ignorerar värdnamnet helt. Den skillnaden avgör om en DNS-redigering räcker eller om varje profil behöver ett nytt fingeravtryck. En poständring bör aldrig auktorisera en slutpunkt som ingen har godkänt.

Håll administrativ åtkomst och återställningsåtkomst borta från det offentliga klientnamnet. Att förlora ett hostingkonto bör inte också kosta dig posten som omdirigerar klienter. Förvara återställningsvägen någonstans som inte beror på leverantören du lämnar.

När varje klient läser namnet igen

Uppslagningstidpunkten är en egenskap per klient, så granska implementeringen du faktiskt levererar innan du lovar ett övergångsfönster. wg-quick slår upp slutpunkten när gränssnittet kommer upp och behåller adressen tills tunneln startas om. En OpenVPN-klient slår upp namnet när den ansluter, och om den tittar igen vid återanslutning beror på dess alternativ.

Mobila klienter är den vanliga överraskningen, eftersom de kan hålla en uppslagen adress genom sömn eller ett nätverksbyte. Publicera A- och AAAA-poster bara om ersättaren svarar i båda familjerna. En adress som svarar i en familj bevisar ingenting om den andra, och en död AAAA-post lägger till en tidsgräns på varje försök. Dokumentera uppslagningsbeteendet för varje klient du stöder och testa sedan på de enheter folk faktiskt använder.

En återanslutning är en användarhandling i de flesta klienter, och servern kan inte tvinga fram den. Skriv in det steget i underhållsanteckningen, med en rad om vad användaren kommer att se när det händer.

Byt över på bevis och avveckla sedan den gamla slutpunkten

Innan bytet, bevisa varje lager på ersättaren: lyssnaren svarar, brandväggen släpper igenom porten, rutterna går rätt tillbaka, namnet slås upp till den nya adressen och en känd identitet accepteras. En lyssnare som tar emot en anslutning är inte samma sak som en som slutför en handskakning, så testa handskakningen och inte porten. Håll den aktuella återkallningslistan bredvid konfigurationen, eftersom en återställd säkerhetskopia återskapar peerlistan som den var och skulle öppna åtkomst du redan har stängt. Anteckna vilken identitet du testade med, eftersom «det fungerar» inte är ett bevis någon kan upprepa.

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

Under övergången, bevaka anslutningsförsök på båda slutpunkterna för samma identitet. En klient som fortfarande autentiserar mot den gamla adressen är en profil eller ett cachelagrat svar som aldrig flyttade sig. Avveckla den gamla slutpunkten enligt en daterad plan, eftersom två tjänster som accepterar en identitet lämnar två dörrar öppna.

Övergångstestet är en applikationssession genom den nya slutpunkten, inte en ping. När den sessionen fungerar och den gamla slutpunkten inte loggar några auktoriserade försök under en full återanslutningscykel, är flytten klar.