Otwórz sekcję routingu swojego klienta VPN, a zobaczysz dwa odmiennie zbudowane elementy sterujące, które często noszą tę samą etykietę. Jeden prosi o wylistowanie miejsc docelowych należących do tunelu, a wszystko inne nadal korzysta z sieci lokalnej. Drugi zakłada, że wszystko idzie przez tunel, i pyta, co wyciąć z powrotem. Oba dają działający tunel już przy pierwszym teście i oba utrzymuje się, dopisując wiersze do listy, dlatego różnica pozostaje niewidoczna, dopóki ktoś nie zainstaluje czegoś nowego.

Wybór jest ustawieniem domyślnym, a nie funkcją. Rozstrzygnij go, zanim lista będzie mieć dwadzieścia pozycji.

Odczytaj ustawienie domyślne z klienta, nie z folderu reklamowego

WireGuard czyni tę decyzję nietypowo widoczną, ponieważ AllowedIPs jest listą włączania i niczym więcej. Peer z 0.0.0.0/0, ::/0 tuneluje wszystko; peer z 10.20.0.0/16 tuneluje tylko to. Nie ma składni wykluczania, więc jeśli chcesz zostawić jedną podsieć poza tunelem, musisz albo wyliczyć wszystkie pozostałe prefiksy, albo dodać routing polityk poza interfejsem.

OpenVPN dochodzi do tego samego miejsca z drugiej strony: redirect-gateway def1 instaluje pełny tunel, a jawne dyrektywy route dodają lub nadpisują konkretne prefiksy. Komercyjni klienci zwykle ukrywają oba za polem wyboru i tabelą miejsc docelowych, więc przeczytaj, które z dwóch tabela faktycznie edytuje, zanim zaufasz etykiecie.

Pytanie nie brzmi, jak nazywa się pole wyboru. Pytanie brzmi, co dzieje się z pakietem, którego miejsce docelowe nie występuje na żadnej z dwóch list. Odpowiedz na to na piśmie, a reszta konfiguracji z tego wynika. Jeśli pominiesz pytanie, o pierwszej niewyjaśnionej awarii zdecyduje ten, kto tego dnia siedzi najbliżej klienta.

Prześledź aplikację, której nikt nie dodał

W projekcie opartym tylko na włączaniu ta aplikacja idzie bezpośrednio, przez sieć lokalną, z lokalnym DNS. W projekcie opartym tylko na wyłączaniu przechodzi przez tunel, w zakresie tego, na co pozwala serwer, i to często decyduje, czy nowe narzędzie SaaS działa pierwszego dnia, czy pojawia się zgłoszenie, że VPN je zepsuł.

Żadne z dwóch ustawień nie jest samo w sobie bezpieczniejsze. Włączanie zawęża to, co niesie tunel, i czyni sieć lokalną ścieżką najmniejszego oporu; wyłączanie przyjmuje tunel jako ścieżkę normalną i traktuje wyjątki jako wyjątki, co jest bliższe temu, co większość polityk korporacyjnych naprawdę ma na myśli.

QuestionInclude-onlyExclude-only
Unlisted new appgoes directgoes through the tunnel
A site that breaks over the VPNadd it to the listcarve it out
Internal names still resolveonly if routed and servedusually, until split DNS says otherwise
Upkeepone entry per internal serviceone entry per misbehaving public service

Zwróć uwagę, jakiego rodzaju obiekty listuje platforma

Interfejs VpnService.Builder Androida udostępnia listę aplikacji dozwolonych i listę zabronionych jako dwa osobne modele, a reguły dla aplikacji wybierają według pakietu, a nie według miejsca docelowego. Przeglądarka umieszczona na takiej liście niesie ze sobą każdy otwierany cel, co jest inną ziarnistością niż tabela routingu i nie potrafi naprawić jednej zepsutej witryny wewnątrz działającej aplikacji.

Klienci desktopowi zwykle mieszają oba rodzaje w jednym interfejsie, więc sprawdź, czy dodawany wiersz to pakiet, nazwa hosta czy prefiks. Zawodzą na różne sposoby i rozwiązuje się je w różnych miejscach. Wiersz z nazwą hosta zwykle staje się trasą plus nazwą, a wiersz z pakietem staje się decyzją polityki wewnątrz klienta. Zapisz, który z dwóch dodałeś, bo osoba debugująca później założy ten drugi.

Testuj stan awarii, nie tylko szczęśliwą ścieżkę

Aplikacja wyłączona z tunelu nie dostaje automatycznie czystego dostępu bezpośredniego. Jeśli klient dodatkowo egzekwuje regułę blokującą bez VPN, wyłączony ruch może zostać całkowicie odrzucony, co wygląda na zepsutą aplikację, a nie na decyzję routingu. Przetestuj ten przypadek celowo, zamiast dowiadywać się o nim ze zgłoszenia użytkownika.

Potem sprawdź DNS i IPv6 jako osobne punkty. Tunel, który niesie tylko IPv4, zostawia aplikacji zdolnej do v6 drogę wokół niego, a podzielony DNS decyduje, czy nazwy wewnętrzne rozwiązują się dla ruchu, który wcale nie idzie przez tunel. Uruchom aplikację z listy, aplikację spoza listy, zapytanie o nazwę i jedno ponowne połączenie, i zachowaj wyniki razem z konfiguracją.

Zapisz ustawienie domyślne tam, gdzie znajdzie je następna osoba

Zapisz wybrane ustawienie domyślne, wyjątki i to, kto za nie odpowiada, w tym samym miejscu co profil klienta, bo następny administrator doda wpis bez czytania tego rozumowania. Zanotuj datę i powód każdego wyjątku, żeby nieaktualny wyjątek dla naprawionej witryny można było usunąć z przekonaniem. Lista bez powodów rośnie w nieskończoność.

Kiedy ktoś zgłasza jedno zepsute miejsce docelowe, zmień wyjątek, a nie punkt odniesienia. Odwrócenie ustawienia domyślnego, by naprawić jedną witrynę, po cichu przenosi każdą aplikację spoza listy na drugą stronę tunelu.

Powiązane artykuły