Jak tunel rozdzielony decyduje, który ruch korzysta z VPN

Tunel rozdzielony to polityka routingu wyrażona jako zestaw reguł, i klient jest tylko tym, co je instaluje. Rozdzielenie następuje w dwóch miejscach: reguły dopasowania, które wybierają ścieżkę dla każdego pakietu, i powiązania, które trzymają aplikację na jednym interfejsie, cokolwiek mówi tabela. To, na którym mechanizmie opiera się twój klient, wyjaśnia większość niespodzianek zgłaszanych przez ludzi.

Politykę, którą można wyrazić w jednym wierszu, da się przetestować. Polityka opisana jako szybsze przeglądanie taka nie jest i nie powie, którą regułę zmienić, gdy żądanie pójdzie w złym kierunku.

Klient instaluje reguły, jądro dokonuje wyboru

Gdy tunel wstaje, klient dodaje trasy i często reguły polityki do tej samej tabeli, której używają twoje inne interfejsy. Każdy pakiet trafia wtedy do wyszukiwania, które porównuje jego cel z każdym kandydackim prefiksem i zachowuje najbardziej szczegółowe dopasowanie, a priorytet rozstrzyga remisy między regułami wskazującymi różne tabele. Nic w tym wyszukiwaniu nie wie, że pakiet przyszedł z karty przeglądarki, a nie z zadania kopii zapasowej. Wygrywa reguła, która wyznacza ścieżkę, i można ją odczytać przed zmianą i po niej.

Dlatego tunel rozdzielony może wydawać się dowolny. Dwa cele w jednej aplikacji mogą iść różnymi ścieżkami tylko dlatego, że jeden prefiks jest węższy od drugiego.

Ten sam wybór istnieje na każdej platformie, choć nazwy się zmieniają. Windows wpycha decyzję do swojej platformy filtrów, Android udostępnia listę dozwolonych aplikacji przez swoją usługę VPN, a macOS przypina tunel do urządzenia, które nadal słucha tabeli routingu. Notatki Microsoftu o routingu są warte przeczytania dla przypadku Windows, a przewodnik napisany dla jednej platformy rzadko przenosi się bez zmian na inną.

Powiązanie z aplikacją i prefiksy celu to różne narzędzia

Polityka celu pyta, dokąd idzie pakiet, i konsultuje tabelę tras lub regułę polityki. Polityka dla aplikacji pyta, który program otworzył gniazdo, i platforma trzyma ten program na interfejsie tunelu nawet wtedy, gdy bardziej szczegółowa trasa wskazuje gdzie indziej. Druga jest silniejsza, bo przetrwa zmiany tabeli, ale obejmuje tylko procesy, które platforma potrafi przypisać. Proces pomocniczy, wbudowana przeglądarka lub usługa otwierająca własne połączenie mogą nie odziedziczyć powiązania, które zakładałeś.

Żadne z tych podejść nie przetrwa polityki opartej na nazwach bez pomocy. Adresy dużych witryn rotują między sieciami treści, więc przypięcie nazwy hosta do kilku prefiksów tworzy regułę, która po cichu przestaje pasować. Polityka, która musi podążać za nazwami, potrzebuje komponentu świadomego resolvera, a nie statycznej trasy.

DNS i przełącznik bezpieczeństwa kierują się własnymi regułami

Rozwiązywanie nazw to decyzja odrębna od routingu pakietów, a tunel rozdzielony zwykle chce dwóch resolverów: firmowego dla nazw wewnętrznych, lokalnego dla całej reszty. Klient może zainstalować ustawienia DNS dla każdego interfejsu, przekazać zapytania resolverowi pośredniemu lub zostawić domyślne ustawienie systemu nietknięte. Przeglądarka z własnym szyfrowanym resolverem omija wszystkie trzy rozwiązania. Przetestuj wyszukiwanie, zamiast zakładać, że resolver poszedł za trasą.

Przełącznik bezpieczeństwa dodaje filtr na wierzchu, a ten filtr nie zawsze odróżnia zamierzone wykluczenie od przypadkowego wycieku. Niektóre klienty blokują wszystko poza tunelem, inne pozwalają na wykluczenia deklarowane przez politykę, więc przeczytaj, jakie zachowanie implementuje twój, zanim zaufasz któremukolwiek.

Sprawdź rozdzielenie z obu stron

Przetestuj ścieżkę dołączoną i ścieżkę wykluczoną osobno, a wynik oceń po nazwie interfejsu, a nie po adresie publicznym. Te polecenia zakładają hosta Linux z już podniesionym urządzeniem tunelowym. Zastąp 203.0.113.10 celem, który twoja polityka kieruje do wewnątrz, a 198.51.100.25 celem, który wysyła na zewnątrz.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Czytaj pierwsze dwie odpowiedzi razem, bo interfejs nazwany w każdej z nich pokazuje, czy rozdzielenie umieściło ten cel w tunelu. Zapytanie do resolvera pokazuje, który serwer odpowiedział na nazwę wewnętrzną, a ostatnie polecenie dowodzi, że urządzenie tunelowe w ogóle potrafi przenieść żądanie. Błąd w drugiej linii, gdy pierwsza się udaje, oznacza, że polityka robi dokładnie to, co jej kazano.

Powtórz zestaw po ponownym połączeniu i po zmianie sieci. Odnowienie dzierżawy i rotacja interfejsów to miejsca, w których rozdzielenie przestaje odpowiadać intencji, dla której je zbudowano, a zapisany wynik każdego uruchomienia czyni dryf oczywistym.