VPN się przeniósł: dlaczego klient OpenVPN nadal wybiera stary adres IP

Dostawca zmienił twój publiczny adres, zaktualizowałeś dynamiczny rekord DNS, a klient nadal nie może się połączyć. Z zewnątrz wygląda to tak, jakby rekord się nie rozprzestrzenił. Najczęściej rekord jest w porządku, a klient wybiera adres, który rozwiązał przed przeprowadzką, ponieważ działający tunel i zapisany profil mają własne wyobrażenie o tym, gdzie mieszka serwer. Trzy warstwy muszą się zgodzić, a aktualizują się według różnych harmonogramów.

Patrz, co wybiera profil, a nie co mówi DNS

Otwórz połączenie, którego naprawdę używasz, i przeczytaj wiersz remote. Adres liczbowy w nim nigdy nie podąża za aktualizacją nazwy hosta, niezależnie od tego, jak poprawny stanie się rekord.

Następnie sprawdź, czy profil, który edytowałeś, jest tym, który wczytał klient. Importowane profile są częste: administrator mógł miesiące temu zrobić kopię i zachować własną wersję, więc plik w folderze pobierania i wpis w aplikacji mogą się różnić. Porównaj punkt końcowy w danych połączenia samego klienta, zanim w ogóle zaczniesz debugować DNS.

Dwa pliki, jeden punkt końcowy — to tutaj typowe ustalenie.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Przeczytaj następną próbę połączenia klienta

Uruchom połączenie ponownie ze szczegółowym logowaniem i przeczytaj wiersz, w którym nazwany jest adres, z którym się połączy. To ta wartość się liczy, a nie ta rozwiązana przez przeglądarkę.

Pamięć podręczna resolvera może wciąż trzymać poprzednią odpowiedź, a niektóre sieci trzymają ją dłużej, niż wymaga TTL rekordu. Pytaj resolver, którego klient faktycznie używa, a nie publiczny, który testowałeś gdzie indziej.

Jeśli log pokazuje nowy adres, a połączenie nadal zawodzi, problem się przesunął: pakiet gdzieś idzie i nikt nie odpowiada. To kwestia nasłuchu, zapory lub przekierowania portu i leży po stronie serwera, a nie na ścieżce rozwiązywania klienta. Trzymaj te dwa błędy osobno, bo traktowanie nieosiągalnego nasłuchu jako problemu DNS prowadzi cię dwa razy przez tę samą pętlę.

Wiedz, którego restartu dokonujesz

Nie wszystkie restarty zachowują ten sam stan, dlatego zmiana adresu może zachowywać się różnie w zależności od tego, jak proces jest odtwarzany. Miękki restart wywołany sygnałem zachowuje więcej kontekstu poprzedniej sesji, a pełne zatrzymanie i uruchomienie zaczyna od nowa od konfiguracji. Jeśli testujesz, czy klient ponownie rozwiązuje adres, chcesz ścieżki zaczynającej się od konfiguracji.

Ustawienia trwałości też mają znaczenie, bo służą zachowaniu tego, co zostało uwierzytelnione, a nie goniieniu za nowymi adresami.

Najczystszy test to świeży start z docelowego profilu, po którym następuje spojrzenie na wiersz logu nazywający punkt końcowy. Wszystko, czego dowiesz się z częściowo zachowanej sesji, jest twierdzeniem o tej sesji.

Cztery opcje i ich odrębne zadania

remote z nazwą hosta to ustawienie, które w ogóle umożliwia ponowne rozwiązywanie; dosłowny adres w tym wierszu to wyklucza. resolv-retry kontroluje, co się dzieje, gdy wyszukiwanie zawiedzie, a wersja 2.6 domyślnie ustawia ją na nieskończoność. Dodanie jej niczego więc nie zmienia i nigdy nie planuje okresowego sprawdzenia innej odpowiedzi. Kto twierdzi, że odpytuje nowe adresy, ten pomylił odzyskiwanie ze świeżością.

persist-remote-ip dotyczy ciągłości, a nie świeżości: ponownie używa punktu końcowego, który ostatnio się uwierzytelnił, poprzez obsługiwane miękkie restarty. Gdy testujesz przeprowadzkę, to jest odwrotność tego, czego chcesz. Wyłącz go na czas testu, jeśli twoja kompilacja go włącza, a potem przywróć, gdy nowy punkt końcowy zostanie udowodniony. Pozostawiony włączony, udane ponowne połączenie może nic nie powiedzieć o DNS.

float akceptuje uwierzytelnionego partnera, którego adres zmienił się w trakcie sesji, i tylko w konfiguracjach, które to obsługują. Nie odświeża DNS i sam nie podąży za zmianą dostawcy. Traktuj go jako funkcję odporności dla partnerów, którzy się przemieszczają, a nie jako mechanizm dynamicznych adresów dla serwerów.

Potwierdź nowy punkt końcowy, zanim obwinisz klienta

Spoza swojej sieci sprawdź, czy nowy adres ma nasłuch na skonfigurowanym porcie i czy przekierowanie dostawcy na niego wskazuje. Poprawny rekord A dla maszyny bez otwartego portu daje dokładnie ten objaw, który ludzie przypisują pamięci podręcznej.

Potem połącz się ponownie i zweryfikuj dwie rzeczy: klient uwierzytelnił się względem oczekiwanego certyfikatu serwera, a sesja dociera do zasobu, który miałeś na myśli. Zmiana adresu nie obniża wymagań tożsamości, a połączenie, które udaje się do złego punktu końcowego, jest gorsze od tego, które zawodzi. Podręcznik OpenVPN 2.6 wymienia wszystkie cztery opcje z ich własnym zakresem, i to jest lista kontrolna, którą trzyma się obok profilu.

Zapewnij sobie drogę poza pasmem do serwera, zanim zrestartujesz tunel, który przenosi twój dostęp administracyjny. Ten jeden środek ostrożności zapobiega większości incydentów, które ten scenariusz powoduje.