Trwałe trasy dla VPN na Macu: networksetup czy hook połączenia?

Trasa wpisywana po każdym połączeniu rozwiązuje chwilę, a nie tydzień. W macOS trwałym wyborem jest zwykle prefiks przechowywany wraz z usługą VPN, ponieważ usługa instaluje go ponownie przy każdym połączeniu i usuwa, gdy usługa jest wyłączona. Alternatywy to tymczasowy route add do testów i hook połączenia dla adresów znanych dopiero po negocjacji.

Zdecyduj, czy trasa należy do usługi, czy do sesji

Zapytaj, od czego zależy prefiks. Jeśli to stała sieć prywatna za natywną usługą VPN, trasa należy do tej usługi. Jeśli zależy od adresu partnera, który zmienia się przy każdym połączeniu, hook lub zadanie sterowane stanem może być lepszym właścicielem. Jeśli sprawdzasz tylko ścieżkę na najbliższe pięć minut, wystarczy trasa tymczasowa.

Trasa powiązana z usługą ma najczystszy cykl życia. Pojawia się z usługą i znika, gdy usługa nie jest połączona, więc nie może przeżyć tunelu, na który wskazuje. Ta właściwość jest warta więcej niż wygoda polecenia w jednej linii.

Trasa powiązana z sesją należy do interfejsu, a ten numer zmienia się bez ostrzeżenia. Ponowne połączenie może dać tunelowi inną nazwę utun niż poprzednia sesja, co zamienia zakodowane na stałe polecenie w trasę, która nie wskazuje niczego lub, co gorsza, inny tunel.

Odczytaj bieżący stan trasy i usługi

Zacznij od nazw, których system naprawdę używa. Nazwa usługi w ustawieniach sieci jest identyfikatorem poniższych poleceń, a bieżąca tabela tras pokazuje, co zainstalował połączony klient. Odczytaj oba, gdy tunel jest aktywny.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

To wyszukanie pokazuje, którą bramę i interfejs jądro wybrałoby dla tego adresu w tej chwili. Jeśli już wybiera tunel, prefiks jest pokryty i nowa trasa byłaby zbędna. Jeśli wybiera lokalny router, tunelowi brakuje tego prefiksu.

Zanotuj adres partnera, gdy jesteś połączony. Staje się wartością bramy w trasie powiązanej z usługą i zwykle jest miejscem docelowym pokazywanym dla trasy domyślnej tunelu w netstat -rn.

Zapisz prefiks za pomocą networksetup

Narzędzie networksetup przyłącza dodatkowe trasy do usługi sieciowej. Dla usługi o nazwie OfficeVPN i prywatnego prefiksu osiąganego przez partnera tunelu forma jest następująca:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Każda trójka po nazwie usługi podaje miejsce docelowe, jego maskę sieci i partnera tunelu jako bramę. Jedno wywołanie może nieść kilka prefiksów, a puste wywołanie czyści zapisaną listę. Czytnik to krok weryfikacji; jeśli lista jest pusta, ustawienie nie zostało zastosowane do usługi, o której myślisz.

Brama musi być partnerem tunelu, a nie fizycznym routerem. Trasa, która nazywa lokalną bramę, wysyła prywatny prefiks przez fizyczny interfejs, co jest pierwotną awarią z dodatkowymi krokami. Nieaktualny partner to najczęstsza przyczyna, dla której poprawnie wyglądająca trasa nigdy nie przenosi ruchu. Odczytaj partnera ponownie ze stanu połączenia, zamiast kopiować adres ze starej notatki.

Używaj route add tylko do testu

Trasa bezpośrednia jest przydatna, by udowodnić, że prefiks działa, zanim uczynisz go trwałym. Forma z interfejsem unika wyszukiwania bramy:

sudo route -n add -net 10.20.0.0/16 -interface utun4

Trasa znika przy następnym połączeniu i zależy od numeru interfejsu, który istnieje dziś. To czyni ją diagnostyką, a nie wdrożeniem. Jeśli test działa, a trasa powiązana z usługą nie, porównaj najpierw wartość bramy; to pole najczęściej jest błędne.

Uważaj na porady, które zastępują domyślną trasę VPN, by wymusić podział. Klient wymuszający pełny tunel może ponownie zainstalować swoje trasy po ponownym połączeniu lub odświeżeniu polityki, więc ręczna zmiana jest po cichu cofana. Kilka prywatnych prefiksów to problem routingu; utrzymywanie całego ruchu internetowego lokalnie wbrew polityce pełnego tunelu to decyzja po stronie serwera.

Wybierz hook tylko wtedy, gdy adres jest negocjowany

Dla łączy opartych na PPP, takich jak L2TP, macOS uruchamia /etc/ppp/ip-up po zestawieniu łącza. Skrypt otrzymuje nazwę interfejsu oraz wynegocjowane adresy lokalny i zdalny, więc może dodać trasę zależną od partnera przydzielonego przez serwer. To dokładnie ten przypadek, którego stała trasa usługi nie potrafi wyrazić.

IKEv2 i klienci producentów mogą w ogóle nie używać tej ścieżki PPP, co oznacza, że skrypt może milczeć przez całą sesję. Gdy tak się dzieje, równoważnym mechanizmem jest zadanie launchd, które odpytuje scutil --nc status i reaguje na zmianę stanu, z niewielkim opóźnieniem.

Niezależnie od użytego hooka, uczyń go idempotentnym i pozwól mu usuwać tylko trasy, które sam utworzył. Skrypt, który usuwa każdą trasę wspominającą tunel, w końcu usunie trasę utrzymującą osiągalność serwera VPN, a połączenie spadnie, gdy tylko się powiedzie.

Zakończ, sprawdzając miejsce docelowe prywatne, zwykłe przeglądanie oraz cykl ponownego połączenia lub uśpienia. Następnie zbadaj scutil --dns, ponieważ rozwiązywanie nazw to osobna polityka, a działająca trasa nie dowodzi, że prywatne nazwy się rozwiązują.