Przenoszenie serwera VPN na nowy publiczny adres IP: co sprawdzić najpierw

Ponowne przypisanie adresu zajmuje minutę. Następny tydzień to miejsce, w którym przenosiny się psują, i rzadko tam, gdzie sugeruje to konsola dostawcy. Nowy publiczny adres IP jest przywoływany w czterech miejscach: gnieździe, na którym nasłuchuje demon, zakotwiczeniu zaufania, które weryfikują klienci, każdej regule nazywającej stary adres oraz rekordzie DNS, który je wiąże. Dwa przeniesienia wyglądają w panelu sterowania identycznie, ale zachowują się zupełnie inaczej: ponowne przypisanie adresu na maszynie, którą zarządzasz, albo postawienie drugiego endpointu i przeniesienie na niego klientów. Poniższe kontrole stawiają tanie awarie na początku, a każda sekcja mówi, do którego przeniesienia się odnosi.

Zamiana w miejscu i przełączenie równoległe to różne zadania

Zamiana w miejscu zachowuje host, klucze, tablicę routingu i listę użytkowników; zmienia się tylko adres. To robi ponowne przypisanie pływającego IP, a u kilku dostawców gość w ogóle tego nie zauważa, bo translacja odbywa się przed instancją. Przebudowa lub ponowne przypisanie przez dostawcę jest ostrzejsze: gość widzi zmianę, a wszystko, co pamiętało starą wartość w cache, dowiaduje się o niej w tej samej chwili.

Równoległy endpoint to drugi host wykonujący tę samą pracę. Zbuduj go, przetestuj jednym profilem i pozwól staremu odpowiadać, dopóki nowy nie udowodni się na realnej ścieżce. Ceną jest stan. Bez wspólnych wpisów peer, unieważnień i logowania masz dwie sieci, które przypadkowo dzielą nazwę.

Znajdź każde miejsce, w którym zapisano stary adres

Zacznij od przeszukania tekstu, bo pliki konfiguracji to łatwiejsza połowa. Przeszukaj konfigurację demona, fragmenty firewalla, cele monitoringu i każdy wygenerowany pakiet klienta na dysku. Uwzględnij adres IPv6, jeśli taki publikujesz; przeniesienie, które śledzi tylko rekord A, zostawia klientów z podwójnym stosem na starej ścieżce.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Potem przejrzyj jądro, bo działający system trzyma adres w miejscach, których żaden plik nie wymienia. Statyczna reguła źródłowego NAT, wpis ipset, adres bind i wpis conntrack przeżywają zmianę konfiguracji, która je usunęła, a niektóre przeżywają też restart, bo wróciły z zapisanego zestawu reguł. Jedną warstwę wyżej grupy zabezpieczeń dostawcy, cele load balancera i kontrole monitoringu w ogóle nie są w twoim systemie plików.

Zapisz inwentarz, zanim cokolwiek zmienisz; służy też jako skrypt wycofania.

Klienci z nazwą hosta wracają do zdrowia; klienci z dosłownym IP milkną

Jeśli klienci docierają do serwera po nazwie hosta, przełączenie to głównie problem DNS, a TTL ustawiony wczoraj decyduje, jak źle będzie. Resolvery cachują, resolvery stub cachują ponownie, a wiele klientów szuka nazwy tylko przy nowym połączeniu, więc ustanowiony tunel zachowuje swój początkowy adres.

Jeśli endpoint to adres dosłowny, nic nie jest rozwiązywane ponownie i nic nie zapisuje skargi. WireGuard przechowuje rozwiązaną adres gniazda: Endpoint = vpn.example.net:51820 staje się IP w momencie, gdy uruchamia się wg-quick up, i pozostaje tym IP, dopóki go nie zmienisz. OpenVPN jest łagodniejszy: rozwiązuje nazwę hosta remote w chwili połączenia i z resolv-retry infinite ponownie próbuje DNS przy ponownym połączeniu. Z dosłownym IP oba nadal wybierają maszynę, której już nie ma.

To, co ludzi myli, to lustrzane odbicie. Klient już wskazujący na nowy adres, podczas gdy stary nasłuch wciąż odpowiada, przechodzi każdy test, który wykonasz ze swojego biurka. Mnie też to zmyliło: nowy endpoint wstał na telefonie za pierwszym razem, a klient z nieaktualnym profilem ujawnił się dopiero, gdy stary nasłuch wyłączono znacznie później.

Zaufanie nie przenosi się z adresem

WireGuard oddziela tożsamość od osiągalności, co czyni przeniesienie adresu prawie darmowym. Peery są identyfikowane kluczem publicznym, a endpoint to tylko miejsce, do którego pakiety aktualnie idą; host aktualizuje endpoint peera na podstawie adresu źródłowego ostatniego uwierzytelnionego pakietu. Bezczynny peer nadal potrzebuje powodu, by rozmawiać z nowym miejscem, i uczy się adresu dopiero wtedy, gdy jego sesja się zestarzeje, a ponowienia handshake zawodzą w widocznym miejscu. Skrócony przewodnik WireGuard omawia pole endpoint.

Serwery oparte na TLS to przypadek odwrotny. Certyfikat jest związany z nazwą, a klient, który wybiera adres, porównuje to, co wybrał, z nazwami alternatywnymi podmiotu. Połącz się przez IP z certyfikatem niosącym tylko DNS SAN, a weryfikacja zawiedzie: nazwa użyta przez klienta nie ma jej w certyfikacie. Ponowne wydanie z IP SAN naprawia to jedno połączenie i pogarsza następne przeniesienie. Trzymanie nazwy hosta w profilu i pozostawienie verify-x509-name na miejscu utrzymuje kontrolę ścisłą, podczas gdy adres pod spodem się zmienia.

Potem sprawdź, do czego przypisany jest demon; gniazdo przypięte do starego adresu zawodzi po cichu. Serwer OpenVPN uruchomiony z local 203.0.113.10 odmawia wstania, gdy tego adresu zabraknie, podczas gdy nasłuch na 0.0.0.0 podąża za zmianą za darmo. NAT dzieli się tak samo: MASQUERADE podąża za adresem, który maszyna ma teraz, a statyczny SNAT --to-source 203.0.113.10 dalej przepisuje na adres, którego już nie posiadasz, więc ruch powrotny znika. Jeśli nowy adres przychodzi z inną bramą upstream, sprawdź rp_filter: filtrowanie odwrotnej ścieżki odrzuca ruch powrotny przychodzący na interfejs, którego jądro się nie spodziewało.

Kolejność przełączenia i dowody, że zadziałało

Obniż TTL dzień wcześniej, postaw nowy nasłuch i udowodnij go profilem, który masz tylko ty. Test od wewnątrz tej samej sieci nie dowodzi prawie niczego, więc użyj telefonu w sieci komórkowej i przetestuj coś, co tunel ma przenosić, a nie ping do endpointu.

Obserwuj oba adresy przez cały czas. wg show all latest-handshakes na nowym hoście lub plik stanu OpenVPN powie ci, ile peerów naprawdę się przeniosło. Gdy nowy endpoint ma oczekiwane peery, a stary tylko maruderów, wycofaj stary nasłuch, usuń nieaktualną regułę NAT i usuń adres z firewalla dostawcy. Usunięcie starego nasłuchu to krok, który się pomija, i zamyka lukę, w której nieaktualny profil wciąż dociera do starej sieci.

Zapisz na piśmie wyzwalacz wycofania przed rozpoczęciem: jeśli nowy endpoint nie ma handshake od ani jednego realnego klienta po uzgodnionym oknie, przywróć stary adres i przestań rozdawać profile. Uruchom przeszukanie ponownie i potwierdź, że żaden nasłuch nie jest już przypisany do wycofanego adresu. Dwie rzeczy przechodzą do następnego przeniesienia: nazwa hosta w profilu klienta, aby następna zmiana była edycją DNS, oraz inwentarz przechowywany obok notatek odzyskiwania serwera.