Aplikacja przypisana do interfejsu? Jej ścieżka VPN nie jest domyślna

Jedna aplikacja na maszynie wychodzi przez VPN, a inna nie, i obaj użytkownicy przysięgają, że nic nie zmienili. Różnica to często decyzja o przypisaniu podjęta przez samą aplikację: gniazdo powiązane z urządzeniem, adres źródłowy wybrany przed połączeniem albo przestrzeń nazw z własną tablicą routingu. Każda z nich zmienia to, która ścieżka obowiązuje, i żadna nie pojawia się w ogólnym sprawdzaniu IP w przeglądarce.

Trzy różne przypisania, trzy różne skutki

Przypisanie do urządzenia i przypisanie do adresu źródłowego to pokrewne operacje o różnych skutkach. Przypisanie do urządzenia może wymusić wyjście ruchu przez jeden interfejs i ominąć normalne wyszukiwanie trasy dla tego gniazda. Przypisanie adresu źródłowego nadal przechodzi przez wybór trasy, ale wybrane źródło może pasować do reguły polityki i wysłać pakiet gdzie indziej. Rozróżnienie brzmi akademicko, dopóki reguła nie zacznie routować według źródła. Wtedy decyduje o wszystkim.

Przestrzeń nazw sieci to trzeci przypadek. Ma własne interfejsy i własną tablicę routingu, więc aplikacja w jej wnętrzu w ogóle nie odczuwa domyślnego ustawienia hosta. Traktowanie wszystkich trzech jako tego samego daje pewne siebie wyjaśnienia, które nie przechodzą pierwszego testu.

Ustal, co aplikacja naprawdę ustawia

Przeczytaj konfigurację sieciową aplikacji lub jej udokumentowane zachowanie, zanim dotkniesz tras. Jeśli udostępnia wybór interfejsu, pole adresu źródłowego lub opcję przestrzeni nazw, to właśnie to ustawienie należy sprawdzić najpierw. Jeśli nie, przypisanie może być wewnętrzne i widoczne tylko przez śledzenie lub własną diagnostykę.

W Linuxie opcje gniazda takie jak SO_BINDTODEVICE mają udokumentowany zakres i wymagania dotyczące uprawnień, a proces bez uprawnień może w ogóle nie móc ich ustawić. To ograniczenie jest użyteczną wskazówką: jeśli opcji nie da się zastosować, aplikacja prawdopodobnie nie jest źródłem różnicy.

Routing polityki czyta źródło

Gdy skonfigurowany jest routing polityki, reguła może wybrać tablicę na podstawie źródła pakietu. Dlatego gniazdo przypisujące adres źródłowy może podążać za regułą, której domyślna ścieżka nigdy nie dotyka, nawet jeśli żaden interfejs nie został nazwany wprost.

Odtwórz wyszukiwanie z tą samą rodziną adresów, źródłem i przestrzenią nazw, których używa aplikacja. Ogólne wyszukiwanie trasy z powłoki w przestrzeni nazw hosta odpowiada na inne pytanie, a ta rozbieżność jest najczęstszą przyczyną wyglądu zepsutej trasy, która działa.

Tunel dzielony i procesy pomocnicze

Tunel dzielony na aplikację dodaje kolejną warstwę. Klient może dopasowywać pakiet lub proces aplikacji, a pomocnik otwierający własne gniazdo jest osobnym podmiotem. Launcher i jego usługa w tle mogą wytwarzać różne połączenia pod tą samą widoczną nazwą.

Sprawdź, czy reguła tunelu dzielonego obejmuje proces, który faktycznie się łączy. Jeśli aplikacja przypisuje się do konkretnego interfejsu, a klient VPN dopasowuje według pakietu, obie decyzje mogą się różnić, choć żadna nie jest błędna.

Testuj własną ścieżkę aplikacji

Po każdej zmianie uruchom nowe żądanie z aplikacji. Przeglądarka pokazująca pożądane wyjście nie jest równoważnym dowodem dla innego programu przypisanego do innego interfejsu, a połączenia w pamięci podręcznej mogą długo używać starej ścieżki po zmianie ustawienia. Zamknij starą sesję, zanim ocenisz nową regułę. Inaczej test mierzy przeszłość.

Dokumentacja gniazd Linuxa opisuje SO_BINDTODEVICE i jego wymagania. Najpierw przeczytaj konfigurację samej aplikacji, odtwórz wyszukiwanie w tym samym kontekście i dopiero potem zdecyduj, czy zmienić trasę, czy przypisanie.