Czy pełne tunelowanie jest prostsze niż długa lista split-tunnelingu?

Lista split-tunnelingu zaczyna się od trzech aplikacji, a kończy na objęciu większości maszyny, i każdy nowy wiersz jest czyimś wyjątkiem. W tym momencie lista po cichu stała się ustawieniem domyślnym z dodatkowymi krokami. Pełne tunelowanie odwraca układ: wszystko wchodzi do tunelu, chyba że udokumentowane wyłączenie mówi inaczej. To, czy jest to prostsze, zależy od bramy i od usług lokalnych, które byś zepsuł.

Zacznij od policzenia reguł, które utrzymujesz

Policz wpisy, a potem policz, ile z nich ma nazwanego właściciela i datę ostatniej weryfikacji. Liczy się ta druga liczba, bo wyjątku bez właściciela nie da się ocenić, gdy oprogramowanie, do którego się odwołuje, zostanie przemianowane lub zastąpione. Reguły powiązane ze ścieżką pliku wykonywalnego zawodzą po cichu po aktualizacji, a awaria wygląda jak niestabilny VPN, a nie jak nieaktualna reguła. Zapisz listę, zanim wyrobisz sobie o niej zdanie.

Każdy wpis powinien odpowiadać na trzy pytania: co się psuje bez niego, kto tak zdecydował i jak zauważysz, że powód wygasł. Wpisy, które nie potrafią odpowiedzieć na wszystkie trzy, są kandydatami do usunięcia, a nie do migracji, a usunięcie ich najpierw sprawia, że późniejsze porównanie jest uczciwe.

Jeśli większość wpisów kieruje dużą część ruchu, już prowadzisz pełny tunel z dołączonym obciążeniem utrzymaniowym. Decyzja dotyczy wtedy tego, gdzie mieszka ustawienie domyślne, a nie tego, czy je mieć.

Sprawdź, czy brama uniesie ustawienie domyślne

Pełne tunelowanie przenosi każdy pakiet do jednego urządzenia, co jednocześnie zmienia obciążenie CPU, tablicę conntrack, tłumaczenie adresów i zapotrzebowanie na przepustowość łącza tego urządzenia. Brama, która wygodnie obsługiwała kilka podsieci wewnętrznych, mogła nie być dobrana do całego przeglądania jednego użytkownika. Patrz na największą oczekiwaną liczbę równoczesnych sesji, a nie na średnią, bo szczyt psuje się pierwszy.

ip -s link show dev tun0
conntrack -C
ss -s

Zmierz to samo obciążenie przed zmianą i po niej, zamiast wnioskować ze specyfikacji. Jedno popołudnie zwykłego użytkowania na jednej maszynie pokaże, czy brama jest blisko limitu, i nic to nie kosztuje w porównaniu z odkryciem tego w poniedziałek rano.

Sprawdź też path MTU od końca do końca, bo pełne ustawienie domyślne naraża każdą aplikację na maksymalny rozmiar pakietu tunelu. Aplikacje, które działały poza tunelem, mogą teraz zależeć od zachowania fragmentacji, o którym nigdy nie musiałeś myśleć.

Potwierdź, że usługi lokalne i prywatny DNS nadal działają

Wylicz, co musi zostać lokalne, według protokołu, a nie nazwy aplikacji: protokoły odkrywania dla drukarek i ekranów, mostek smart home, strona zarządzania routerem, lokalny serwer deweloperski osiągany po nazwie, która rozwiązuje się tylko w sieci LAN. To psuje się, gdy trasa domyślna zaczyna wskazywać do tunelu, i psuje się cicho, bo nic nie zapisuje błędu po stronie klienta.

Prywatny DNS to druga zależność. Jeśli nazwy wewnętrzne były wcześniej rozwiązywane przez resolver tunelu, nic się nie zmienia; jeśli rozwiązywały się lokalnie, pełne ustawienie domyślne musi przenieść je do resolvera, który zna strefy. Przetestuj jedną nazwę wewnętrzną i jedną publiczną po zmianie, zamiast zakładać, że lista resolverów przetrwała.

Zapisz lokalne wyjątki w profilu, do którego należą. Wyjątek trzymany tylko w czyjejś pamięci jest pierwszą rzeczą, którą traci następna migracja.

Zmigruj jeden profil i zweryfikuj granice

Zmień profil przez konfigurację, która nim zarządza, a nie przez nałożenie nowego ustawienia domyślnego na ręczne trasy pozostawione przez wcześniejsze eksperymenty. Te pozostałe trasy są zwykłą przyczyną migracji, która wygląda na działającą i zachowuje się niespójnie dzień później. Utrzymuj stary profil w gotowości, aby wycofanie było wyborem, a nie odbudową.

Następnie zweryfikuj osobno dwie granice: że cele publiczne i prywatne działają, oraz że niechciany ruch nie wychodzi poza tunel. Udane wczytanie strony dowodzi pierwszego i nic nie mówi o drugim.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Powtórz kontrolę po ponownym połączeniu i po awarii, bo kill switch blokujący ruch podczas zerwania to inna właściwość niż trasa, która potem wraca poprawnie. Prostszą konstrukcją jest ta, której rzeczywiste pokrycie nadal potrafisz wyjaśnić po zmianie aplikacji lub sieci.