Změna poskytovatele VPN: naplánujte název hostitele, ne jen IP
Nový záznam DNS nepřesune existující relace. Naplánujte, kdo ovládá název, kdy jej každý klient překládá a jak vyřadíte starý koncový bod.
Váš záznam DNS je správný, náhrada je v pořádku, a přesto někteří klienti tráví hodiny vytáčením staré adresy. Několik jich okamžitě selže proti názvu, který se přeloží a nikdy neodpoví. Oba výsledky pramení z jedné mezery: název hostitele mění, co klient hledá, ne kdy to hledá, ani čemu věří, když odpověď dorazí.
Příznak: správný záznam, zastaralé tunely
Profil, který ukládá název, není klient, který jej neustále překládá. Většina jej přeloží jednou — při aplikaci konfigurace nebo při spuštění tunelu — a pak tuto adresu znovu používá až do konce relace. Dlouhý TTL navrch je důvod, proč se přechod musí plánovat kolem opětovných připojení, a ne kolem úpravy DNS.
Ani jedno chování není vada, a právě to dělá příznak matoucím. Klient pracuje s odpovědí, kterou získal dříve, a nic na straně serveru neukazuje, která odpověď to byla. Naplánujte opětovné připojení do servisního okna a řekněte uživatelům, co uvidí, nebo okno strávte odpovídáním na tikety. Fronta identických hlášení je obvyklý výsledek.
Kdo ovládá název a co klient ověřuje
Kontrola nad zónou rozhoduje o tom, jak rychle může migrace postupovat. Udržujte záznam u registrátora, do kterého se můžete přihlásit, a zapište, kdo další jej může změnit.
Důvěra nenásleduje název. Klient založený na TLS může kontrolovat identitu certifikátu nebo připnutý název, zatímco WireGuard ověřuje veřejný klíč protějšku a název hostitele zcela ignoruje. Tento rozdíl rozhoduje, zda úprava DNS stačí, nebo zda každý profil potřebuje nový otisk. Změna záznamu by nikdy neměla autorizovat koncový bod, který nikdo neschválil.
Udržujte administrativní přístup a přístup pro obnovu mimo veřejný název klienta. Ztráta hostingového účtu by vás neměla stát také záznam, který přesměrovává klienty. Uložte cestu k obnově někam, kde nezávisí na poskytovateli, kterého opouštíte.
Kdy každý klient znovu čte název
Načasování překladu je vlastnost jednotlivého klienta, proto si před slibem přechodového okna prohlédněte implementaci, kterou skutečně dodáváte. wg-quick překládá koncový bod při spuštění rozhraní a tuto adresu si drží, dokud se tunel nerestartuje. Klient OpenVPN hledá název při připojení a zda se podívá znovu při opětovném připojení, závisí na jeho volbách.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Mobilní klienti jsou obvyklým překvapením, protože mohou držet přeloženou adresu přes spánek nebo změnu sítě. Zveřejňujte záznamy A a AAAA jen tehdy, když náhrada odpovídá na obou rodinách. Adresa, která odpovídá na jedné rodině, nic nedokazuje o druhé, a mrtvý záznam AAAA přidává časový limit ke každému pokusu. Zdokumentujte chování překladu pro každého klienta, kterého podporujete, a pak testujte na zařízeních, která lidé skutečně používají.
Opětovné připojení je u většiny klientů akce uživatele a server jej nemůže vynutit. Uveďte tento krok v servisní poznámce spolu s řádkem o tom, co uživatel uvidí, až se to stane.
Přejděte na základě důkazů a potom vyřaďte starý koncový bod
Před přepnutím dokažte každou vrstvu na náhradě: posluchač odpovídá, firewall propouští port, trasy se vracejí správným směrem, název se překládá na novou adresu a známá identita je přijata. Posluchač, který přijme spojení, není totéž jako ten, který dokončí handshake, proto testujte handshake, a ne port. Mějte aktuální seznam odvolání vedle konfigurace, protože obnovená záloha znovu vytvoří seznam protějšků tak, jak byl, a znovu by otevřela přístup, který jste už zavřeli. Zapište, s jakou identitou jste testovali, protože „funguje“ není důkaz, který by někdo mohl zopakovat.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesBěhem přechodu sledujte pokusy o připojení na obou koncových bodech pro stejnou identitu. Klient, který se stále autentizuje proti staré adrese, je profil nebo uložená odpověď, která se nikdy nepřesunula. Vyřaďte starý koncový bod podle datovaného plánu, protože dvě služby přijímající jednu identitu nechávají otevřené dvoje dveře.
Testem přechodu je aplikační relace přes nový koncový bod, ne ping. Jakmile tato relace funguje a starý koncový bod nezaznamená žádné autorizované pokusy během celého cyklu opětovného připojení, přesun je dokončen.