Promjena VPN provajdera: planirajte ime hosta, ne samo IP

Vaš DNS zapis je ispravan, zamjena je zdrava, a neki klijenti ipak satima biraju staru adresu. Nekoliko ih odmah padne na imenu koje se razrješava i nikada ne odgovara. Oba ishoda dolaze iz jedne praznine: ime hosta mijenja šta klijent traži, ne kada to traži, i ne čemu vjeruje kada odgovor stigne.

Simptom: ispravan zapis, zastarjeli tuneli

Profil koji čuva ime nije klijent koji ga stalno razrješava. Većina razrješava jednom — pri primjeni konfiguracije ili kada se tunel podigne — a zatim ponovo koristi tu adresu do kraja sesije. Dug TTL naslagan na to razlog je zašto se prelazak mora planirati oko ponovnih veza, a ne oko DNS izmjene.

Ni jedno ponašanje nije defekt, i upravo to simptom čini zbunjujućim. Klijent radi s odgovorom koji je ranije dobio, a ništa na strani servera ne pokazuje koji je to odgovor bio. Planirajte ponovnu vezu u servisni prozor i recite korisnicima šta će vidjeti, ili provedite prozor odgovarajući na tikete. Red identičnih prijava uobičajen je rezultat.

Ko kontrolira ime i šta klijent provjerava

Kontrola zone određuje koliko brzo migracija može ići. Držite zapis kod registrara u koji možete ući i zapišite ko ga još može mijenjati.

Povjerenje ne slijedi ime. Klijent zasnovan na TLS-u može provjeravati identitet certifikata ili prikovano ime, dok WireGuard autentificira javni ključ partnera i potpuno ignorira ime hosta. Ta razlika odlučuje je li DNS izmjena dovoljna ili svaki profil treba novi otisak. Promjena zapisa nikada ne smije autorizirati endpoint koji niko nije odobrio.

Držite administrativni pristup i pristup za oporavak dalje od javnog imena klijenta. Gubitak hosting računa ne treba da vas košta i zapisa koji preusmjerava klijente. Čuvajte put oporavka negdje što ne zavisi od provajdera kojeg napuštate.

Kada svaki klijent ponovo čita ime

Vrijeme razrješavanja svojstvo je pojedinog klijenta, zato provjerite implementaciju koju zaista isporučujete prije nego obećate prozor prelaska. wg-quick razrješava endpoint kada se interfejs podigne i zadržava tu adresu dok se tunel ne restartuje. OpenVPN klijent traži ime kada se povezuje, a hoće li ponovo pogledati pri ponovnoj vezi zavisi od njegovih opcija.

Mobilni klijenti su uobičajeno iznenađenje, jer mogu zadržati razriješenu adresu kroz san ili promjenu mreže. Objavljujte A i AAAA zapise samo ako zamjena odgovara na oba adresna tipa. Adresa koja odgovara na jednom tipu ništa ne dokazuje o drugom, a mrtav AAAA zapis dodaje tajmaut svakom pokušaju. Dokumentujte ponašanje razrješavanja za svakog klijenta kojeg podržavate, pa testirajte na uređajima koje ljudi zaista koriste.

Ponovna veza je u većini klijenata radnja korisnika i server je ne može prisiliti. Stavite taj korak u servisnu bilješku, s redom o tome šta će korisnik vidjeti kada se to dogodi.

Pređite na osnovu dokaza, pa povucite stari endpoint

Prije prebacivanja dokažite svaki sloj na zamjeni: slušalac odgovara, firewall propušta port, rute se vraćaju ispravnim putem, ime se razrješava na novu adresu i poznati identitet je prihvaćen. Slušalac koji prihvati vezu nije isto što i onaj koji dovrši rukovanje, zato testirajte rukovanje, a ne port. Držite trenutnu listu opoziva uz konfiguraciju, jer vraćeni backup ponovo stvara listu partnera onakvom kakva je bila i otvorio bi pristup koji ste već zatvorili. Zapišite s kojim ste identitetom testirali, jer „radi“ nije dokaz koji bilo ko može ponoviti.

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

Tokom tranzicije pratite pokušaje povezivanja na oba endpointa za isti identitet. Klijent koji se još autentificira prema staroj adresi jest profil ili keširani odgovor koji se nikada nije pomjerio. Povucite stari endpoint po planu s datumom, jer dvije usluge koje prihvataju jedan identitet ostavljaju dvoja vrata otvorena.

Test prelaska je aplikacijska sesija kroz novi endpoint, a ne ping. Kada ta sesija proradi i stari endpoint ne zabilježi nijedan autorizirani pokušaj tokom punog ciklusa ponovne veze, premještanje je završeno.