Zielona ikona, ten sam publiczny IP: którą trasę VPN pominął

Połączono, zielona ikona w zasobniku i strona odbijająca adres, która nadal pokazuje adres dostawcy, nie oznaczają automatycznie awarii. Klient wykonuje dwie osobne prace: buduje tunel i edytuje tablicę routingu. Każda może się zdarzyć bez drugiej, a routing selektywny to konfiguracja, w której druga jest celowo pomijana.

Co klient faktycznie zainstalował

Zapytaj, który interfejs poniósłby pakiet do rzeczywistego celu, zamiast pytać, czy tunel jest podniesiony. Tunel bez trasy do tego celu to prywatna droga, po której nikt nie jeździ.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Pierwsze polecenie odpowiada w Linuksie i macOS, a pozostałe dwa to odpowiedniki w Windows, gdzie wystarczy jedno. Jeśli odpowiedź wskazuje kartę fizyczną, tunel jest podniesiony, a trasa domyślna nigdy się nie przesunęła. Powtórz sprawdzenie dla celu, który powinien korzystać z tunelu, bo dwa sprawdzenia, jedno odległe i jedno zwykłe, mówią, który projekt jest wdrożony.

Trzy formy routingu selektywnego

Profil pełnego tunelu zapisuje zwykle trasę domyślną na interfejs albo zapisuje parę prefiksów połowy zakresu, które wygrywają długością prefiksu, podczas gdy pierwotna trasa domyślna zostaje w tablicy. Routing selektywny to drugi wybór i występuje w kilku formach. Jeden profil kieruje pojedynczy host, na przykład serwer RDP, inny kieruje zakres publiczny, do którego trzeba dotrzeć z konkretnego miejsca, a trzeci celowo wyklucza jedną aplikację. Wszystkie trzy są legalne i żaden nie zmienia adresu, który widzi zwykła strona.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Przeczytaj profil pod kątem dyrektywy, która decyduje, a potem tablicę pod kątem tego, co wytworzyła. Wepchniętą dyrektywę można też stłumić na kliencie, dlatego profil i tablica muszą się zgadzać, zanim obwinisz serwer.

Druga strona musi przepisać adres źródłowy

Istnieje druga awaria, która z przeglądarki wygląda identycznie. Trasa prowadzi w tunel, serwer odbiera pakiety, a następnie przekazuje je z nietkniętym prywatnym adresem klienta. Następny skok nie ma drogi powrotnej dla tego adresu, więc odpowiedzi znikają, a strony zawieszają się. Serwer musi w ogóle przekazywać i musi przetłumaczyć źródło na coś, co internet potrafi z powrotem wytrasować.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Nazwij interfejs, który naprawdę patrzy w internet, a w nowoczesnej dystrybucji nie zawsze jest to eth0. Hostowany serwer ze stałym adresem może tłumaczyć wprost na ten adres zamiast używać masquerade. Obie połowy są ważne, bo przekazywanie bez tłumaczenia wycieka źródła, których nie da się wytrasować, a tłumaczenie bez przekazywania nigdy nie widzi pakietu.

Rozwiązywanie nazw idzie własną drogą

Ruch może wychodzić przez tunel, podczas gdy zapytanie, które znalazło nazwę, poszło do resolvera w sieci lokalnej. Widoczny adres pozostaje ten sam, zapytania nie, i właśnie tę lukę wybiera projekt dzielonego DNS.

resolvectl status | head -20
resolvectl query example.org

Zwróć uwagę, który serwer odpowiedział i czy różni się od linii bazowej sprzed tunelu. W tunelu dzielonym to zwykle to ustawienie, które ludzie chcieli zmienić, gdy narzekali na adres, i właśnie to, na które nigdy nie spojrzeli.

Cztery obserwacje, które rozstrzygają sprawę

Zapisz adres wyjściowy przy opuszczonym tunelu, a potem przy podniesionym. Wykonaj sprawdzenie celu w obu stanach i za każdym razem zanotuj interfejs.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Gdy sprawdzenie trafi w tunel, a echo nadal pokazuje adres dostawcy, brakuje tłumaczenia na wyjściu. Gdy sprawdzenie trafi na kartę fizyczną, profil jest selektywny i publiczny adres nigdy nie był w grze. Zastąp usługę echa taką, której ufasz, i zapisz cztery obserwacje razem, bo osobno są anegdotami. Razem wskazują, którą z dwóch prac klient naprawdę wykonał.