FortiClient pełny tunel: kieruj tylko podsieć biurową

Tunel wstaje, ikona zmienia kolor na zielony i lokalna sieć znika: drukarki, NAS i router biurowy przestają odpowiadać. FortiClient robi to, czego zażądał profil. Brama wysłała trasę domyślną, klient ją zainstalował i każdy pakiet ma teraz drogę do tunelu. Poprawka to zmiana tabeli tras ze zmianą DNS za nią, a kolejność tych zmian decyduje, czy maszyna skończy lepiej, czy gorzej.

Co zainstalował klient i dlaczego LAN zniknął

Zacznij od czytania tabeli, a nie interfejsu klienta. W macOS netstat -rn wypisuje całą tabelę, a route -n get default nazywa interfejs i metrykę, które obecnie wygrywają; w Linuxie para to ip route show i ip route get 8.8.8.8. Oba odpowiadają na jedno pytanie: który wpis poniesie pakiet, który nie pasuje do niczego bardziej szczegółowego.

Nazwa urządzenia tunelu nie jest stała. Profil IKEv2 w macOS zwykle pokazuje utun z numerem, klient SSL VPN pokazuje ppp0, a OpenVPN pokazuje tun0. Dwie trasy domyślne mogą też być obecne jednocześnie z różnymi metrykami, a wpis klienta może przejąć kontrolę dopiero po ponownym połączeniu, a nie w chwili pojawienia się. Dlatego dwa zrzuty tabeli wykonane w odstępie pięciu minut mogą opowiadać różne historie.

Dlaczego trasa domyślna tunelu musi zniknąć pierwsza

Jądro wybiera najdłuższy pasujący prefiks, a gdy kilka tras jest równie szczegółowych, wybiera tę o najniższej metryce. Klient, który instaluje 0.0.0.0/0 z lepszą metryką, wygrywa więc każde miejsce docelowe bez usuwania oryginalnej trasy domyślnej, i dlatego trasa fizyczna nadal jest w tabeli i nadal wyjaśnia awarię. Usunięcie najpierw trasy domyślnej tunelu przywraca poprzednie zachowanie. Dopiero potem trasa prefiksu przez tunel robi to, co zamierzał jej autor.

Dodawanie prefiksów przed tym krokiem to błąd, który daje na wpół działającą maszynę. Ruch do nowego prefiksu idzie przez tunel, a wszystko, czego nie ma na liście, także idzie przez trasę domyślną tunelu, więc nic nie wygląda na zepsute, dopóki ktoś nie otworzy usługi, której nikt nie dodał. Usuń, przywróć, potem dodaj, a stan pośredni pozostaje przewidywalny.

Kolejność w macOS i w Linuxie

W macOS ta kolejność usuwa trasę domyślną tunelu, przywraca fizyczną trasę domyślną i wysyła jeden prefiks biura z powrotem do tunelu. Zastąp przykładowe nazwy interfejsów tymi z własnej tabeli.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

W Linuxie ta sama kolejność używa innego narzędzia: bramy LAN dla trasy domyślnej i urządzenia tunelu dla prefiksu biura. Stare polecenie route nadal przyjmuje starą składnię, ale ip route to forma zgodna z obecną dokumentacją.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Gdy trasa potrzebuje następnego skoku, a nie urządzenia, weź peer z wyjścia klienta. Zgadywanie daje jeden z dwóch błędów, a znaczą one co innego: zła brama daje natychmiast network unreachable, a zły cel tunelu daje przekroczenie czasu. Przeczytaj, który otrzymałeś, zanim znów zmienisz polecenie.

Prefiksy, resolver i DMZ, która pozostaje ciemna

Jeden prefiks rzadko pokrywa całą pracę. Serwery aplikacji, sieci zarządzania, DMZ i same serwery DNS mogą znajdować się w różnych zakresach, więc wypisz każdy zakres, jaki potrafisz nazwać, zanim zaczniesz, i przy każdym ping sprawdź jedno zapytanie. Miejsce docelowe odkryte w trakcie testu to właśnie to, które zostaje zapomniane w rejestrze zmian. Trasa, która odpowiada po adresie, ale zawodzi po nazwie, to zwykle problem resolvera w kostiumie routingu.

Resolver to osobna decyzja. Gdy profil wysłał wewnętrzne serwery DNS, odebranie trasy domyślnej może pozostawić te adresy nieosiągalne dla nazw publicznych albo osiągalne tylko przez tunel, a oba stany dają mylące częściowe wyniki. Skieruj adresy resolvera przez tunel albo skonfiguruj rozwiązywanie na domenę, aby zapytania publiczne korzystały z lokalnego resolvera.

Klient SSL w Linuxie ma awarię specyficzną dla pola, którą warto znać: tunel się łączy, biurowy LAN odpowiada, a jeden zakres DMZ pozostaje ciemny. Brakującym elementem jest trasa do tego zakresu przez bramę tunelu, a brama różni się między maszynami, więc zaszyty na stałe adres to sposób, w jaki psuje się następny laptop. Wyprowadź ją ze stanu klienta i utrzymaj polecenie samodokumentujące się:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Przeczytaj dwie wartości, zanim je uruchomisz. peer to odległy koniec tunelu punkt-punkt i to adres, którego potrzebuje trasa DMZ; w tunelu routowanym odpowiednikiem jest interfejs lub brama raportowana przez klienta. Jeśli żaden się nie pojawi, klient nie jest w trybie, który zakładałeś.

Po następnym połączeniu i kiedy przestać robić to lokalnie

FortiClient łączy się ponownie po uśpieniu lub zmianie sieci i ponownie instaluje to, co określa profil. Trasy ręczne przetrwają więc tylko do następnego połączenia, a to dokładnie ten przedział, w którym jeden udany test może wyglądać jak naprawa. Trasa, która znika w nocy, jest oczekiwanym zachowaniem, a nie nową usterką.

Istnieją dwie trwałe odpowiedzi. Skrypt, który powtarza poprawkę po każdym połączeniu, jest obejściem, które może przeżyć swojego autora, natomiast profil tunelu dzielonego od administratora bramy jest prawdziwą naprawą, bo klient instaluje wtedy tylko zakresy potrzebne do pracy. Poproś o drugie, a pierwsze stosuj tylko w czasie oczekiwania. Sprawdź też politykę, na którą się zgodziłeś, przed lokalnym podziałem pełnego tunelu, bo sieć zdalna może polegać na widzeniu całego twojego ruchu.

Lista kontrolna jest krótka: przeczytaj tabelę, usuń trasę domyślną tunelu, przywróć trasę domyślną LAN, dodaj każdy prefiks, napraw rozwiązywanie osobno i oczekuj, że trasy wrócą po ponownym połączeniu.