VPN połączony, ale adres IP się nie zmienił: dlaczego

Łączysz się, klient mówi połączono, a test adresu wciąż pokazuje ten sam numer co wcześniej. Wskaźnik nie jest niczemu winien; coś między profilem a aplikacją zostawiło to żądanie poza tunelem. Zdecyduj, na którą z trzech rzeczy patrzysz, zanim dotkniesz jakiejkolwiek konfiguracji: test, który nigdy nie zmierzył adresu publicznego, tunel obejmujący tylko część ruchu albo druga ścieżka, która wygrywa decyzję routingu. Każda ma jedną kontrolę trwającą mniej niż minutę.

Potwierdź, co test faktycznie zmierzył

Adres w oknie Wi-Fi lub Ethernet to adres interfejsu w twoim własnym segmencie, a nie adres widziany przez witrynę, więc może pozostać taki sam, gdy tunel działa bezbłędnie. Lokalizacja to znowu osobny sygnał: zapisany region konta lub dozwolony odczyt geolokalizacji nie przesuwa się, gdy zmieniasz wyjście, a logowanie, które cię już rozpoznaje, też nie.

Użyj echa adresu publicznego i pytaj każdą rodzinę osobno, bo wynik testu z podwójnym stosem ukrywa interesujący przypadek:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Uruchom oba przed połączeniem i po nim. Jeśli odpowiedź IPv4 zmienia się na adres wyjściowy, a odpowiedź IPv6 nie, nie masz zepsutego tunelu; jedna rodzina jedzie poza nim. Jeśli obie odpowiedzi pozostają takie same, żądanie nigdy nie dotarło do tunelu i reszta tutaj się stosuje.

Profil może obejmować tylko część ruchu

Profil z tunelem dzielonym to zwykła odpowiedź i nie jest to usterka. OpenVPN wysyła wszystko przez tunel tylko wtedy, gdy redirect-gateway jest w przekazanych opcjach; bez niego klient dostaje kilka konkretnych tras, a twoja trasa domyślna zostaje na łączu fizycznym. W Windows ten sam przełącznik pojawia się jako „Użyj bramy domyślnej w sieci zdalnej” we właściwościach IPv4 karty, a jego wyłączenie to świadomy wybór, który przetrwa każde ponowne połączenie.

Zakres na aplikację to druga warstwa. Ustawienie VPN na aplikację w Androidzie decyduje, które aplikacje są objęte, więc klucz VPN na pasku stanu nie dowodzi, że przeglądarka jest w środku. Rozszerzenie przeglądarki, które proxuje własny ruch, tworzy lustrzany obraz: przeglądarka pokazuje adres wyjściowy, podczas gdy klient poczty lub gra na tej samej maszynie wciąż pokazuje twój. Porównaj to samo żądanie w dwóch aplikacjach. Jeśli jedno się zmienia, a drugie nie, patrzysz na zakres, nie na zawodzący tunel.

Jedna rodzina adresów nadal może iść bezpośrednio

Większość profili VPN napisano dla IPv4, i wiele wciąż takich jest. W sieci z podwójnym stosem tunel bierze 10.8.0.x dla IPv4, podczas gdy łącze fizyczne zachowuje globalny adres IPv6 i trasę domyślną, więc witryna obsługująca IPv6 jest osiągana bezpośrednio, a adres, który zgłasza, należy do twojego dostawcy. To wyciek przy działającym tunelu IPv4, niewidoczny dla testu mówiącego tylko IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Czytaj interfejs w każdej odpowiedzi. Jeśli wyszukiwanie IPv6 wskazuje twoje urządzenie Ethernet lub Wi-Fi, a wyszukiwanie IPv4 wskazuje tunel, polityki dla tej rodziny brakuje, a nie jest zepsuta. Wyłączenie IPv6 na całym urządzeniu usuwa objaw i ukrywa decyzję; lepiej napraw pokrycie profilu albo wyłącz rodzinę tylko na tym połączeniu i zapisz, którą z dwóch opcji wybrałeś.

Druga ścieżka może wygrać wyszukiwanie

Konkurujące proxy, drugi klient VPN, wirtualny adapter z kontenera lub narzędzia zdalnego pulpitu albo dodatkowa trasa dokładnie dla testowanego prefiksu mogą przejąć pierwszeństwo. Konkretna trasa zawsze bije trasę domyślną, więc pozostały /24 dla mierzonej witryny, wskazujący na twoją bramę LAN, nadal wysyła ten ruch poza tunel, niezależnie od kondycji tunelu.

Zrób inwentarz, zanim cokolwiek zmienisz, poleceniami tylko do odczytu:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Szukaj więcej niż jednej trasy domyślnej z wiarygodną metryką oraz konkretnej trasy obejmującej cel. W przeglądarce sprawdź też, czy połączenie należy do rozszerzenia proxy lub ustawienia proxy systemu; rozszerzenie może wskazać własny upstream i zostawić wyjście systemu operacyjnego nietknięte, co daje inny adres w przeglądarce niż w terminalu na tej samej maszynie.

Zmierz ponownie ze świeżym żądaniem

Połącz się ponownie, a potem powtórz pomiar z tej samej aplikacji, której użyłeś za pierwszym razem, bo strona z pamięci podręcznej lub ponownie użyte połączenie zgłasza stary stan. Obserwuj dziennik lub widok zdarzeń klienta podczas łączenia: błąd przy stosowaniu tras po uwierzytelnieniu jest silniejszym dowodem niż jakikolwiek wskaźnik i zwykle wskazuje trasę lub adapter, który zawiódł.

Trzymaj dwa wyniki osobno. Jeśli adres się zmienia, ale jedna witryna wciąż cię odrzuca, tunel działa, a witryna odrzuca adres centrum danych; to inny problem z inną odpowiedzią. Jeśli adres nigdy się nie zmienia, przejdź cztery pytania po kolei: jaki adres wypisał test, która to była rodzina, która aplikacja zrobiła żądanie i którą trasę to żądanie obrało. Dokumentacja Microsoftu o decyzjach routingu VPN wyjaśnia, jak klient Windows wybiera między tunelem a adapterem fizycznym, gdy oba mają trasę.