Dodatkowe trasy VPN na Macu potrzebują właściciela, nie skryptu logowania
Trasa dodana raz przy logowaniu nie jest polityką ponownego łączenia. Daj zdalnym prefiksom właściciela i zdecyduj, jak pojawiają się, zmieniają i znikają wraz z tym połączeniem.
Osiągnięcie prywatnego prefiksu przez VPN jest wymaganiem z czasem trwania: obowiązuje, dopóki to połączenie jest użyteczne, i kończy się, gdy kończy się połączenie. Skrypt logowania nie potrafi tego wyrazić, bo logowanie i podniesienie tunelu to różne momenty, a tunel istniejący przy logowaniu może nie być tym, który minutę później niesie ruch. Pierwsza decyzja to nie to, które polecenie uruchomić. To, który komponent posiada prefiks.
Prefiks potrzebuje właściciela, a nie momentu
Zacznij od zapisania wymagania jako zdania z podmiotem: osiągnij 10.77.0.0/24 przez VPN biurowy, dopóki to połączenie jest podniesione. To zdanie nazywa prefiks, połączenie i warunek, i od razu wyklucza dwa popularne zamienniki: hook logowania i nazwę interfejsu, taką jak ppp0 lub utun2.
Nazwy interfejsów są nadawane w czasie działania i nie są stabilne między ponownymi połączeniami. Hook, który pasuje do nazwy widzianej w zeszłym tygodniu, albo nie zadziała, albo zadziała na cudzym interfejsie. Oba wyniki wyglądają jak błąd routingu, a nie jak przestarzałe założenie, którym są. Ten sam zarzut dotyczy każdego skryptu opartego na nazwie, która istnieje tylko dopóki podniesiony jest jeden konkretny tunel.
Użyj obsługiwanego źródła intencji trasy
Brama, zarządzany profil lub udokumentowany mechanizm tras klienta będącego właścicielem to właściwe miejsce, gdy ten mechanizm potrafi wyrazić wymaganie. Który obowiązuje, zależy od protokołu i dostawcy, a klucze nie wędrują między nimi, więc wartość konfigurująca profil OpenVPN nie mówi nic o natywnym kliencie L2TP ani IKEv2.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
Dla twórców tuneli pakietowych ustawienia tunelu IPv4 firmy Apple jawnie udostępniają trasy dołączone i wykluczone, a IPv6 ma swój odpowiednik. To API, których używa dostawca, a nie dowód, że każdy natywny panel VPN oferuje administratorowi dowolną listę tras. Jeśli obecna kombinacja nie potrafi wyrazić potrzebnych prefiksów, następnym krokiem jest obsługiwana ścieżka konfiguracji od operatora, a nie inna aplikacja zainstalowana w nadziei, że zachowa się lepiej.
Czas życia obejmuje sprzątanie
Czasem zewnętrzny pomocnik jest naprawdę potrzebny, a wtedy „dodaj trasę” to najmniejsza część jego pracy. Musi wiedzieć, któremu połączeniu służy i którego interfejsu używa to połączenie, poczekać, aż odpowiedni stan sieci się ustabilizuje, pozostać idempotentnym przy dwóch uruchomieniach z rzędu, i nie sprzątać niczego, czego sam nie zainstalował.
Ostatnia klauzula jest tą, która boli. Pomocnik, który usuwa każdą trasę pasującą do prefiksu biurowego, prędzej czy później usunie trasę, której nie dodał. Wynikająca z tego awaria jest zrzucana na klienta VPN, bo klient to część, którą widzi użytkownik. Rozstrzygnięcie, co pomocnik posiada, przed jego napisaniem jest tańsze niż późniejsze wyjaśnianie, dlaczego lokalna podsieć przestała odpowiadać.
Wyścig przy ponownym połączeniu
Wyobraź sobie szybkie ponowne połączenie. Sesja A pada, sesja B wstaje i instaluje swoją trasę, a potem w końcu uruchamia się opóźnione sprzątanie A. Jeśli to sprzątanie usuwa trasy według prefiksu, zabiera ze sobą ważny stan B, a połączenie, które działało sekundę temu, kieruje teraz donikąd.
To wyścig o własność, a dodanie snu do skryptu zmienia tylko to, która strona go wygrywa. Rozwiązaniem jest uzależnienie sprzątania od tożsamości: porównaj interfejs i sesję zainstalowane przez pomocnika z tymi wciąż aktualnymi i usuwaj tylko przy zgodności.
Co testować i czego trasa nie potrafi
Akceptacja musi obejmować cztery przejścia: pierwsze połączenie, ponowne połączenie na inny interfejs, nieudaną próbę połączenia i końcowe rozłączenie. Po każdym z nich odczytaj trasę, którą system faktycznie wybrał dla adresu po drugiej stronie, a nie tę, której oczekiwałeś.
route -n get 10.77.0.5
netstat -rn -f inetUwzględnij też niewygodne przypadki w tym samym przebiegu: IPv6 tam, gdzie jest wymagany, prefiks lokalny nakładający się na zdalny oraz trasę do samego publicznego punktu końcowego VPN, która musi działać, dopóki tunel jest podniesiony. Potem zapisz, czym trasa nie jest. Wybiera pakiety; nie daje uprawnień po stronie zdalnej i nie tworzy drogi powrotnej, a to pozostają odrębne wymagania z odrębnymi właścicielami.
Oczekiwany rezultat to prefiks, który podąża za swoim obsługiwanym właścicielem połączenia przez każde przejście, a nie polecenie, które raz przypadkiem się udało na maszynie, na której je napisano.