Split tunneling oparty na aplikacji a oparty na miejscu docelowym: co wybrać

Split tunneling oparty na aplikacji i oparty na miejscu docelowym to nie dwa ustawienia do tego samego zadania. Jedno pyta, który proces wysyła pakiet; drugie pyta, dokąd ten pakiet zmierza. Reguła zbudowana pod pierwsze pytanie cicho zawodzi, gdy ruch pochodzi z procesu pomocniczego, a reguła pod drugie zawodzi, gdy nazwa hosta rozwiązuje się na adres, którego nigdy nie wpisano. Wybierz obiekt pasujący do wymagania, a następnie udowodnij to dwoma pakietami testowymi: jeden musi korzystać z tunelu, drugi nie może.

Dwie reguły działają na różnych warstwach

Reguła aplikacji jest egzekwowana powyżej warstwy sieciowej, wobec tożsamości, którą system operacyjny przypisuje nadawcy. W Androidzie to UID stojący za pakietem, a usługa VPN decyduje dla każdego UID, czy ruch wchodzi do tunelu. O miejscu docelowym nic nie jest pytane, więc wybrana aplikacja może dotrzeć wszędzie, a żadna inna aplikacja nie może dotrzeć do sieci wewnętrznej.

Reguła miejsca docelowego jest egzekwowana na samym pakiecie. Interfejs tunelu posiada zbiór prefiksów, tablica routingu kieruje do niego pasujący ruch, a proces wysyłający jest nieistotny. Dlatego reguła miejsca docelowego obejmuje usługę, drukarkę albo zadanie wsadowe, którego nikt nie pamiętał wpisać, i dlatego nie da się jej wyrazić jako dokładnie ten program na platformie, której klient nigdy nie patrzy na proces.

Reguły aplikacji pasują do klientów mobilnych i zarządzanych agentów

Android pokazuje wybór bezpośrednio: VpnService.Builder.addAllowedApplication() i addDisallowedApplication() przyjmują nazwy pakietów i egzekwują decyzję dla każdego UID, jak opisano w przewodniku dewelopera VPN Androida. iOS ma odpowiednik w postaci reguł VPN dla poszczególnych aplikacji opartych na identyfikatorach pakietów, zwykle dostarczanych przez profil MDM, a nie wpisywanych ręcznie.

Klienci desktopowi są słabym punktem. Większość klientów VPN dla Windows i macOS routuje według miejsca docelowego i w ogóle nie oferuje wyboru według procesu, ponieważ sterownik tunelu widzi pakiety, a nie procesy. Jeśli twoja koncepcja zależy od tunelowania jednej aplikacji na laptopie, sprawdź rzeczywiste możliwości klienta, zanim zaczniesz na tym budować; być może wybierasz między listą miejsc docelowych a drugim komputerem.

Wniosek, który ludzie pomijają: na tych platformach nie da się naśladować reguły aplikacji trasami. Dodanie trasy hosta dla serwera aplikacji tuneluje ruch wszystkich do tego serwera, łącznie z przeglądarką i aktualizatorem.

Reguły miejsca docelowego pasują do list podsieci i dostępności witryn

WireGuard czyni model jawnym. AllowedIPs to routing klucza kryptograficznego: pakiet wewnętrzny, którego miejsce docelowe mieści się na liście peera, jest szyfrowany do tego peera, a wszystko inne wychodzi nieszyfrowane zwykłą drogą. Nie ma procesu do nazwania ani niejasności co do tego, co jest objęte.

OpenVPN dociera w to samo miejsce przez wypychaną tablicę tras. route-nopull powstrzymuje serwer przed dyktowaniem tras, po czym po stronie klienta route 10.20.0.0 255.255.0.0 vpn_gateway obejmuje dokładnie prefiks biura. IPv6 jest osobnym poleceniem w każdym z tych klientów, a zapomnienie o nim to najczęstszy sposób wycieku wokół poprawnie wyglądającego podziału IPv4.

Nazwa hosta nie jest trasą. Jeśli profil oferuje pole domeny, traktuj je jako nazwę, którą klient rozwiązuje raz, a nie jako stały zakres adresów; sieci dostarczania treści i równoważenia obciążenia jutro zwrócą inne adresy.

Gdzie pękają oba modele: pomocnicy, usługi współdzielone, resolvery

Procesy pomocnicze łamią reguły aplikacji w sposób, który wygląda jak awaria serwera. Aktualizator przeglądarki, raportownik awarii, usługa synchronizacji uruchomiona jako SYSTEM i WebView osadzony w innym pakiecie to odrębne tożsamości, więc tunelowanie przeglądarki może pozostawić rzeczywiste żądanie poza tunelem. Odwrotnie jest równie mylące: wykluczona aplikacja, która wywołuje współdzieloną bibliotekę wewnątrz tunelowanego procesu, nadal ma ruch przez tunel.

Reguły miejsca docelowego pękają na współdzielonych usługach i na nazwach. Udziały plików, drukarki, wewnętrzny DNS i serwer licencji żyją pod adresami, więc tunel jednej aplikacji daje przeglądarce dostęp, podczas gdy zmapowany dysk pozostaje martwy. Ta różnica pokrycia nie jest błędem żadnego z modeli, ale to ona sprawia, że tunel jednej aplikacji tak często daje sytuację, w której VPN działa, a udział zniknął.

Resolvery przecinają oba. Jeśli klient ustawia wewnętrzne serwery DNS, ale system operacyjny używa DNS przez HTTPS do publicznego resolvera, odpowiedź przychodzi spoza tunelu i reguła miejsca docelowego może nigdy nie pasować. Sprawdź, który resolver rzeczywiście odpowiedział, zanim uznasz regułę za błędną, i potwierdź po stronie klienta, czy w ogóle zainstalował resolver tunelu. Podział, który zostawia DNS poza tunelem, wygląda w tablicy routingu perfekcyjnie i mimo to zawodzi na każdej nazwie wewnętrznej.

Procedura: wybierz, zastosuj, zweryfikuj

Zacznij od wymagania, nie od menu. Jeśli celem jest, aby tylko ta aplikacja mogła korzystać z tunelu, potrzebujesz reguł aplikacji i platformy, która je obsługuje. Jeśli celem jest, aby te sieci były osiągalne przez tunel, potrzebujesz prefiksów. Jeśli odpowiedź brzmi oba, zaimplementuj je jako dwie osobne kontrole i zapisz, która odpowiada za którą awarię.

Zastosuj najwęższą formę, jaką potrafisz wyrazić, a potem zweryfikuj, pytając tablicę routingu, a nie ikonę stanu klienta:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Pierwsze dwa wiersze nazywają interfejs, którego użyłby rzeczywisty cel; wg show wypisuje skonfigurowaną listę prefiksów; w Windows Find-NetRoute odpowiada na to samo pytanie, na które odpowie stos przy wysyłaniu pakietu. Jeśli interfejsem jest tunel, reguła pasuje.

Następnie przetestuj drugi pakiet, który powinien zostać wykluczony, z innej aplikacji, do tego samego celu. Zanotuj w zgłoszeniu wersję klienta, typ reguły, listę prefiksów lub pakietów oraz dwa zaobserwowane wyniki. Właśnie ta para wyników mówi następnemu inżynierowi, czy polityka jest źle skonfigurowana, czy ruch nigdy do niej nie należał.