Zmiana dostawcy VPN: zaplanuj nazwę hosta, nie tylko adres IP
Nowy rekord DNS nie przenosi istniejących sesji. Zaplanuj, kto kontroluje nazwę, kiedy każdy klient ją rozwiązuje i jak wycofasz stary punkt końcowy.
Twój rekord DNS jest poprawny, zamiennik jest zdrowy, a mimo to niektóre klienty spędzają godziny, wybierając stary adres. Kilka natychmiast zawodzi na nazwie, która się rozwiązuje i nigdy nie odpowiada. Oba wyniki biorą się z jednej luki: nazwa hosta zmienia to, czego szuka klient, nie to, kiedy szuka, ani to, czemu ufa, gdy odpowiedź nadchodzi.
Objaw: poprawny rekord, przestarzałe tunele
Profil, który przechowuje nazwę, nie jest klientem, który ją stale rozwiązuje. Większość rozwiązuje ją raz, przy stosowaniu konfiguracji albo gdy tunel wstaje, a potem używa tego adresu do końca sesji. Długi TTL na tym wszystkim sprawia, że przejście trzeba planować wokół ponownych połączeń, a nie wokół edycji DNS.
Żadne z tych zachowań nie jest defektem i właśnie dlatego objaw jest mylący. Klient pracuje na odpowiedzi uzyskanej wcześniej, a nic po stronie serwera nie pokazuje, która to była odpowiedź. Zaplanuj ponowne połączenie w oknie konserwacji i powiedz użytkownikom, co zobaczą, albo spędź to okno na odpowiadaniu na zgłoszenia. Kolejka identycznych raportów to zwykły wynik.
Kto kontroluje nazwę i co weryfikuje klient
Kontrola nad strefą decyduje o tym, jak szybko może przebiegać migracja. Trzymaj rekord u rejestratora, do którego możesz się zalogować, i zapisz, kto jeszcze może go zmienić.
Zaufanie nie podąża za nazwą. Klient oparty na TLS może sprawdzać tożsamość certyfikatu lub przypiętą nazwę, podczas gdy WireGuard uwierzytelnia klucz publiczny peera i całkowicie ignoruje nazwę hosta. Ta różnica decyduje o tym, czy edycja DNS wystarczy, czy każdy profil potrzebuje nowego odcisku palca. Zmiana rekordu nigdy nie powinna autoryzować punktu końcowego, którego nikt nie zatwierdził.
Trzymaj dostęp administracyjny i dostęp do odzyskiwania z dala od publicznej nazwy klienta. Utrata konta hostingowego nie powinna też kosztować cię rekordu, który przekierowuje klientów. Przechowuj ścieżkę odzyskiwania w miejscu, które nie zależy od dostawcy, którego opuszczasz.
Kiedy każdy klient ponownie czyta nazwę
Moment rozwiązywania jest właściwością każdego klienta, więc sprawdź implementację, którą naprawdę dostarczasz, zanim obiecasz okno przejścia. wg-quick rozwiązuje punkt końcowy, gdy interfejs wstaje, i zachowuje ten adres, dopóki tunel nie zostanie uruchomiony ponownie. Klient OpenVPN szuka nazwy przy połączeniu, a to, czy zajrzy ponownie przy ponownym połączeniu, zależy od jego opcji.
| 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 |
Klienci mobilni to zwykła niespodzianka, ponieważ mogą trzymać rozwiązany adres przez sen lub zmianę sieci. Publikuj rekordy A i AAAA tylko wtedy, gdy zamiennik odpowiada w obu rodzinach. Adres, który odpowiada w jednej rodzinie, niczego nie dowodzi o drugiej, a martwy rekord AAAA dodaje limit czasu do każdej próby. Udokumentuj zachowanie rozwiązywania dla każdego obsługiwanego klienta, a potem testuj na urządzeniach, których ludzie naprawdę używają.
Ponowne połączenie jest w większości klientów działaniem użytkownika i serwer nie może go wymusić. Umieść ten krok w notatce o konserwacji, z linijką o tym, co użytkownik zobaczy, gdy to nastąpi.
Przejdź na podstawie dowodów, a potem wycofaj stary punkt końcowy
Przed przełączeniem udowodnij każdą warstwę na zamienniku: nasłuch odpowiada, zapora przepuszcza port, trasy wracają poprawnie, nazwa rozwiązuje się na nowy adres, a znana tożsamość jest akceptowana. Nasłuch, który przyjmuje połączenie, to nie to samo co ten, który kończy uścisk dłoni, więc testuj uścisk dłoni, a nie port. Trzymaj bieżącą listę unieważnień obok konfiguracji, ponieważ przywrócona kopia zapasowa odtwarza listę peerów taką, jaka była, i ponownie otworzyłaby dostęp, który już zamknąłeś. Zapisz, z jaką tożsamością testowałeś, ponieważ „to działa” nie jest dowodem, który ktokolwiek może powtórzyć.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesPodczas przejścia obserwuj próby połączeń na obu punktach końcowych dla tej samej tożsamości. Klient, który nadal uwierzytelnia się wobec starego adresu, to profil albo odpowiedź z pamięci podręcznej, która nigdy się nie przeniosła. Wycofaj stary punkt końcowy zgodnie z datowanym planem, ponieważ dwie usługi akceptujące jedną tożsamość zostawiają otwarte dwoje drzwi.
Testem przejścia jest sesja aplikacji przez nowy punkt końcowy, a nie ping. Gdy ta sesja działa, a stary punkt końcowy nie rejestruje żadnych autoryzowanych prób przez pełny cykl ponownego połączenia, przenoszenie jest zakończone.