Adres peera zmienił się w środku sesji: co robi OpenVPN float

Laptop przechodzi z Wi-Fi biura do hotspotu w telefonie, tunel trzyma się jeszcze kilka sekund, a potem ruch ustaje, podczas gdy interfejs nadal twierdzi, że jest połączony. Na serwerze lista stanu nadal pokazuje stary publiczny adres. To sytuacja, dla której istnieje float, a zarazem sytuacja, w której ludzie oczekują od niego znacznie więcej, niż robi. Właściwe uchwycenie granicy zamienia mylące zatrzymanie albo w zmianę konfiguracji w jednej linii, albo w zupełnie inne śledztwo.

Co float rozluźnia, a czego nigdy nie rozluźnia

Zwykle sesja dalej rozmawia z tym zewnętrznym adresem i portem, z którymi się zaczęła, a pakiety przychodzące zewsząd indziej są ignorowane. Opcja float usuwa to ścisłe powiązanie, gdy peer już się wykazał, więc zmienione mapowanie źródła może kontynuować tę samą sesję zamiast zostać odrzucone. Nic w kontrolach kryptograficznych się nie zmienia: klucze, certyfikaty i wszelka ochrona HMAC pozostają dokładnie takie, jak skonfigurowano.

To decyzja dla każdego pakietu, a nie polityka dotycząca tego, kto może się łączyć. Nieznana maszyna wysyłająca pakiet z nowego adresu niczego nie udowodniła, a jej pakiet jest odrzucany jak każdy inny nieuwierzytelniony ruch. Tylko ruch przechodzący przez własne uwierzytelnianie sesji może przesunąć zapisany adres peera, i dlatego bezpiecznie jest zostawić float włączony w środowiskach, w których klienci się przemieszczają.

Nie mówi też nic o tunelu wewnętrznym. Przesunięty zewnętrzny adres nie przydziela nowego adresu tunelu, nie zmienia puli i nie daje peerowi dostępu do czegoś nowego. Wewnątrz tunelu przed przemieszczeniem i po nim obowiązują ta sama tożsamość i te same wypchnięte trasy. Przemieszczenie nie negocjuje też ponownie kanału danych, więc wynegocjowany szyfr i klucze trwają dalej.

Pakiet, który przesuwa sesję, musi się uwierzytelnić

Rozpocznij sesję w zwykły sposób wobec skonfigurowanego zdalnego końca, a float zajmuje się tym, co dzieje się, gdy mapowanie się zmienia. Operator komórkowy przenumerowujący w środku strumienia, brama NAT przepisująca swoje mapowanie portu albo laptop przełączający łącze nadrzędne dają ten sam kształt: uwierzytelnione pakiety z nowej krotki, które docierają do sesji wciąż wierzącej w starą.

Gdy pytają, czy float działa, przydatnym dowodem jest ukończone uzgadnianie, po którym nastąpiła zaakceptowana zmiana źródła, a nie wiersz logu tylko o adresie. Powiąż stary i nowy adres zewnętrzny z sesją, która pozostała żywa, a następnie potwierdź, że ruch naprawdę był kontynuowany przez tunel.

Jeśli sesja umiera zamiast się przesuwać, pakiet, który dotarł z nowego adresu, prawdopodobnie nie przeszedł uwierzytelnienia albo w ogóle nie dotarł. Oba przypadki wyglądają z perspektywy klienta identycznie. Na serwerze przechwycenie na interfejsie publicznym mówi, który z nich masz, zanim dotkniesz jakiejkolwiek konfiguracji.

Wykrywanie to całkowicie odrębny mechanizm

float nie rozwiązuje nazw po timerze i nie śledzi dynamicznego rekordu DNS. Jeśli nazwa hosta serwera zacznie się rozwiązywać na nowy adres, bezczynny klient nie ma powodu tego zauważyć i nie ma pakietu od nowego punktu końcowego do uwierzytelnienia. Ten problem należy do logiki ponownego łączenia, do własnego zachowania klienta przy ponownej próbie i do DNS, a nie do float.

Dodanie opcji jeszcze raz nie zrekompensuje braku trasy do nowego adresu. Nie pomoże też, gdy peer milczy, ponieważ milczący peer nigdy nie wysyła uwierzytelnionego pakietu, który coś by przesunął.

Zapora pod spodem też ma głos. Reguła dopuszczająca tylko stary zewnętrzny punkt końcowy blokuje zmieniony adres, zanim OpenVPN w ogóle go zobaczy, i żadna konfiguracja po stronie klienta tego nie naprawia. Przejrzyj cykl życia dozwolonych adresów jako osobne zadanie; rozszerzenie reguły na dowolne źródło wymienia mały problem na duży.

Gdy profil należy do NetworkManagera

Profil wiersza poleceń i zaimportowane połączenie to osobne konfiguracje, a edycja jednej nie dotyka drugiej. Zanim uznasz, że opcja nie jest obsługiwana, ustal, jakiego typu wtyczki naprawdę używa zapisany profil i gdzie mieszkają jego wartości. UUID profilu to identyfikator, który ma znaczenie, gdy coś sprawdzasz lub zmieniasz.

Sprawdź zapisane połączenie, a nie oryginalny plik importu. Wiersz, który przetrwał w pliku .ovpn, niczego nie dowodzi, jeśli aktywny menedżer nigdy go nie zastosował, a edytor bez pola wyboru dla danej opcji też niczego nie dowodzi o możliwościach protokołu.

Nie łataj spakowanej wtyczki, żeby dodać to zachowanie, zwłaszcza nie diffem napisanym dla historycznej wersji niepowiązanego komponentu. Jeśli zainstalowana integracja naprawdę nie potrafi wyrazić tego ustawienia, właściwym krokiem jest obsługiwany profil albo inna ścieżka klienta zatwierdzona przez właściciela wdrożenia.

Udowodnij przejście, zamiast je zakładać

Przeprowadź test tak, jak następuje awaria. Połącz się, sprawdź ruch przez tunel, wymuś zmianę zewnętrznego adresu, a potem sprawdź trzy rzeczy: sesja nadal istnieje, zapisany adres peera się przesunął i rzeczywiste żądanie nadal dociera do celu. Cokolwiek mniej niż wszystkie trzy to odpowiedź częściowa.

Trzymaj dostęp do odzyskiwania dostępny podczas testów, bo eksperymenty z przemieszczaniem mają zwyczaj zostawiać osadzoną maszynę, z której pracujesz. Konsola szeregowa albo trasa poza pasmem zamienia nieudany test w pięciominutowe odzyskiwanie zamiast wizyty na miejscu.

Na koniec opisz tylko ten przypadek, który rzeczywiście sprawdziłeś. Udana zmiana adresu w trakcie sesji nie jest dowodem, że migracje DNS, inna implementacja klienta albo odbudowany profil zachowają się tak samo. Dokumentacja link-options precyzyjnie określa zakres tej opcji; w twoim logu testu powinno być napisane, którą część tego zakresu naprawdę pokryłeś.