Publiczny adres IP się zmienił i VPN przestał przepuszczać ruch

Ponowne połączenie u dostawcy lub zmiana w tłumaczeniu wyżej w łańcuchu zmienia publiczne źródło sesji VPN, a lokalny prywatny adres klienta zwykle pozostaje dokładnie taki, jaki był. Tunel wygląda wtedy na połączony, choć nic pożytecznego przez niego nie przechodzi. Oba spostrzeżenia są prawdziwe jednocześnie i właśnie to czyni raport mylącym.

Przejdź cztery kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie.

Który adres naprawdę się zmienił

Porównaj stan lokalnego interfejsu ze źródłem, które widzi zdalny punkt końcowy, w miejscu, w którym masz prawo patrzeć. Nowy publiczny adres nie oznacza nowej lokalnej bramy, a zmiana lokalnego interfejsu też nie gwarantuje, że publiczne źródło się przesunęło. Tłumaczenie pomiędzy oznacza, że to dwa niezależne fakty. Zapisz dokładną ścieżkę i czas, w którym ją zaobserwowałeś, ponieważ etykieta geolokalizacji skopiowana ze starego raportu odpowiada na inne pytanie.

Zapytaj wprost, czy zmieniło się źródło zewnętrzne, wewnętrzny adres tunelu, czy oba. Tylko pierwsze wyjaśnia partnera, który nadal wysyła na ścieżkę, która już nie istnieje.

Pozwól protokołowi zająć się przemieszczeniem

Protokoły różnią się sposobem dowiadywania się, że partner się przemieścił, a ta różnica ma znaczenie dla pytania, czy w ogóle należy interweniować. WireGuard aktualizuje punkt końcowy partnera, gdy otrzyma pakiet uwierzytelniony jego kluczem, dlatego zmianę adresu można przyjąć bez żadnej konfiguracji. IKEv2 ma MOBIKE w tym samym celu tam, gdzie obsługują go oba końce. Starsze rozwiązania odzyskują sprawność, odbudowując tunel.

Czego nie należy robić, to przyjmować nieuwierzytelniony komunikat jako dowodu, że tożsamość partnera się przesunęła. Sfałszowanie datagramu twierdzącego, że pochodzi z nowego adresu, jest trywialne, a klient wierzy, że można go skierować do punktu końcowego atakującego. Uwierzytelniony protokół jest mechanizmem; powiadomienie nim nie jest.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Wyczyszczenie nieaktualnego zewnętrznego powiązania

Gdy protokół obsługuje roaming, a ruch nadal nie przechodzi, przeszkodą jest często urządzenie przechowujące stan po drodze lub reguła na drugim końcu. Zapora, która śledziła stary przepływ, może zachować nieaktualny wpis, a reguła dostępu po stronie serwera powiązana ze starym źródłem po cichu odrzuci nowe. Wyczyszczenie mapowania i ponowne sprawdzenie reguły jest szybsze niż wymiana poświadczeń.

Utrzymuj wymagane blokowanie przez cały czas badania. Szerokie otwarcie reguł, aby sprawdzić, czy tunel się odbuduje, niczego nie uczy o przyczynie i zostawia wdrożenie w gorszym stanie, niż je zastałeś.

Sprawdź ponownie nowym żądaniem

Sesja aplikacji nawiązana przed zmianą jej nie przetrwa, ponieważ czwórka, na której się opierała, już nie istnieje. Po odzyskaniu wygeneruj nowe żądanie i potwierdź, że się kończy, zamiast patrzeć, jak stare pobieranie stoi na zerze, i wnioskować, że tunel nadal jest zepsuty. Właśnie ta jedna różnica rozwiązuje znaczną część takich raportów.

Potem zapisz obie połowy diagnozy: co zmieniło się wyżej w łańcuchu i który obsługiwany krok odzyskiwania przywrócił przepływ. Następny przypadek będzie szybszy, a notatka jest tym, co go przyspiesza.

Jeśli nowe żądanie się powiedzie, a stare nigdy nie zostanie wznowione, tunel został naprawiony i aplikacja musi się po prostu połączyć ponownie.