Jak reguły domenowe Apple VPN On Demand uruchamiają tunel

Tunel otwiera się, gdy zażądasz jednej wewnętrznej nazwy, i pozostaje zamknięty, gdy następna aplikacja potrzebuje go równie mocno. To nie błąd aplikacji; to kształt reguły domenowej. Konfiguracja on-demand Apple opisuje warunki nawiązania połączenia, a domenowa postać tych warunków zadaje resolverowi systemowemu pytanie, zanim ruszy choćby jeden pakiet. Dwa pytania są stale mylone: kiedy tunel ma się podnieść i co tunel niesie, gdy już istnieje. Pierwsze jest wyzwalaczem, drugie polityką tras i resolvera, a jeden profil zwykle ustawia oba w tym samym payloadzie, dlatego poprawna reguła domenowa nadal może zostawić cię w niewłaściwej sieci.

Wyzwalacz i wybór ruchu leżą w różnych warstwach

Reguła on-demand żyje w słowniku on-demand payloadu VPN: uporządkowana lista reguł, każda z akcją i zestawem warunków dopasowania. System ocenia je, gdy zmienia się łączność lub gdy coś próbuje dotrzeć do sieci, a akcja decyduje, czy tunel zostanie podniesiony, oceniony, rozłączony czy zignorowany. Wszystko to dzieje się w warstwie sieciowej platformy, zanim aplikacja dostanie socket.

To, co następuje, to osobna grupa kluczy: ustawienia IPv4 i IPv6 tunelu, jego trasy dołączone i wykluczone, adresy serwerów DNS oraz w iOS i iPadOS mapowanie na aplikację, które decyduje, które aplikacje mogą w ogóle używać tunelu. Profil może sparować szeroki wyzwalacz z wąską trasą albo wąski wyzwalacz z trasą domyślną. Przeczytaj tylko połowę, a druga będzie wyglądać jak awaria.

Mam profil laboratoryjny, który łączy się, ilekroć zostanie zażądana cokolwiek pod domeną wewnętrzną, ale kieruje do tunelu tylko jedną /16. Robi dokładnie to, co mówi jego payload, i jest to też typ profilu, który generuje zgłoszenia: ludzie zakładają, że połączony tunel oznacza, iż ich ruch jest w nim.

O co reguła domenowa naprawdę pyta resolver

Domenowa postać reguły, często nazywana connect-if-needed, nie sprawdza payloadów pakietów ani nie obserwuje adresów URL. Gdy nazwa jest rozwiązywana, system porównuje ją z domenami w regule i przy dopasowaniu pyta, czy tę nazwę można rozwiązać przez serwery DNS dostarczane przez tunel. Jeśli odpowie resolver tunelu, nazwa liczy się jako wewnętrzna i połączenie się rozpoczyna. Jeśli zamiast tego odpowie resolver lokalny, nazwa jest traktowana jako zewnętrzna i tunel się nie pojawia. Przegląd wdrożenia Apple opisuje to jako wykrywanie sieci, po którym następuje ocena połączenia.

Wynikają z tego dwie konsekwencje. Profil musi wskazać serwery DNS wewnątrz tunelu; reguła domenowa bez resolvera tunelu nie ma czego porównywać, więc ocena nie może dać oczekiwanego dopasowania. A zapytanie musi dotrzeć do resolvera systemowego. Aplikacja lub przeglądarka uruchamiająca własny szyfrowany DNS, rozszerzenie odpowiadające lokalnie albo połączenie z adresem dosłownym nigdy nie wytwarzają rozwiązania nazwy, na które czekała reguła. Jedno z najdłuższych popołudni, jakie spędziłem, skończyło się, gdy odkryłem, że klient przed tunelem używał DNS over HTTPS.

Buforowanie również usuwa wyzwalacz. Nazwa, która już jest w pamięci podręcznej, może zostać rozwiązana bez sondy, która uruchomiłaby tunel, więc reguła działająca wczoraj zawodzi po restarcie albo po tym, jak tunel był przez jakiś czas podniesiony. W macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder resetuje stan; w iOS przełączenie trybu samolotowego lub restart urządzenia daje porównywalny czysty stan.

Zakres dopasowania: nazwy, aplikacje i sieci

Dopasowanie domenowe to jeden typ spośród kilku. Reguła może też dopasowywać typ interfejsu (Wi-Fi, komórkowy, Ethernet) i konkretny SSID, a wpisy na aplikację lub domenę Safari wiążą tunel z jednym przepływem pracy. To powiązanie wyjaśnia dziwne doświadczenie, w którym tylko jedna aplikacja zachowuje się inaczej niż wszystko inne: pozostałe aplikacje są poza zakresem tunelu, więc nadal korzystają ze ścieżki lokalnej, nawet gdy ikona tunelu mówi połączono.

Kolejność jest ważniejsza, niż ludzie oczekują. Reguły są oceniane po kolei i pierwsza dopasowana daje akcję, więc szeroka reguła połącz-przy-dowolnym-Wi-Fi umieszczona nad wąską regułą domenową wygra po cichu i uczyni regułę domenową niemożliwą do przetestowania. Zanim przepiszesz listę domen, potwierdź, że żadna wcześniejsza reguła już nie pasowała.

Dlatego always-on nie jest po prostu surowszą regułą on-demand. Wymuszanie always-on to osobny tryb wdrożenia z własnymi wymaganiami nadzoru i zarządzania; utrzymuje tunel otwarty, zamiast reagować na nazwę. Jeśli potrzebujesz tunelu, który nigdy nie pada, reguła domenowa jest niewłaściwym narzędziem.

Tryby awarii imitujące zepsutą regułę

Większość zgłoszeń, że reguła domenowa nie działa, trafia w jedno z pięciu miejsc, a tylko ostatnie z nich to tekst reguły.

Portale captive zasługują na własną linię, bo Wi-Fi w hotelach i na lotniskach przechwytuje dokładnie to zapytanie, od którego zależy reguła. Dopóki portal nie wpuści urządzenia, serwer DNS tunelu jest nieosiągalny, sonda zawodzi, a awaria wygląda jak źle zapisana domena. Uwierzytelnianie to drugi cichy przypadek: reguła może zadziałać, tunel może zacząć się łączyć, a połączenie ginie na wygasłym certyfikacie lub na monicie, który pojawia się na innym ekranie.

IPv6 tworzy wariant łatwy do błędnej diagnozy. Nazwa z obiema rodzinami adresów może zostać najpierw rozwiązana z rekordu AAAA, podczas gdy lista tras tunelu niesie tylko IPv4. Jedna przeglądarka działa, inna nie, a lista domen jest całkowicie niewinna.

Testuj prawdziwym żądaniem, w tej kolejności

Przeczytaj politykę, zanim zaczniesz zgadywać. W macOS sudo profiles show -type configuration wypisuje zainstalowane profile, w tym payload VPN, scutil --nc list pokazuje stan usługi, a scutil --nc show <service> wypisuje słownik on-demand, którego używa system. Na zarządzanym iPhonie lub iPadzie ten sam payload przychodzi z konsoli zarządzania lub raportu MDM. Logi sieciowe są dostępne z log stream --predicate 'subsystem == "com.apple.networkextension"' w macOS oraz przez konsolę urządzenia, gdy telefon jest podłączony.

Następnie testuj nazwą hosta, o którą nie pytano wcześniej w tej sesji. Wybierz nazwę w strefie DNS tunelu, o której wiesz, że rozwiązuje się wewnętrznie, poproś o nią raz i obserwuj, czy tunel się pojawia. Uruchom to samo zapytanie dwa razy: druga próba ćwiczy ścieżkę pamięci podręcznej, a różnica między nimi mówi ci, czy wyzwalaczem jest rozwiązanie, czy routing.

Gdy tunel jest podniesiony, sprawdź dwie warstwy osobno. netstat -rn -f inet i netstat -rn -f inet6 pokazują, dokąd prowadzi każdy prefiks, scutil --dns pokazuje kolejność resolverów i który interfejs posiada każdy resolver, a nettop -m route pokazuje, który interfejs przeniósł bajty. Jeśli tunel jest podniesiony i resolver jest poprawny, ale zasób nadal zawodzi, przestań edytować regułę; sprawdź autoryzację po stronie serwera i trasę powrotną.

Gdy reguła należy do kogoś innego

Jeśli tunel pojawia się ponownie po rozłączeniu, reguła zwykle należy do profilu, a nie do aplikacji: konfiguracja wypchnięta przez MDM, pozostały profil osobisty albo profil zainstalowany przez innego klienta. sudo profiles show -type configuration plus wyszukanie kluczy on-demand zawęzi to, a ścieżką usunięcia jest profil, nie przełącznik w pasku menu. Usunięcie wpisu usługi lub aplikacji zostawia regułę, a następna instalacja znów ją dziedziczy.

Jeden test rozstrzyga własność: rozłącz, poczekaj, poproś ponownie o wewnętrzną nazwę. Jeśli tunel wróci, wyzwalacz działa zgodnie z projektem, a otwarte pytanie brzmi, kto nim zarządza i czy ten zakres jest tym, czego chcesz.

Zanim zgłosisz to jako błąd, przejdź te same pięć kontroli: adresy resolvera tunelu obecne w payloadzie, nazwa, która nie była w pamięci podręcznej, żadna wcześniejsza reguła, która już pasowała, ścieżka AAAA objęta listą tras oraz aplikacja w zakresie tunelu. Gdy wszystkie pięć się zgadza, reguła robi swoje, a usterka jest dalej na ścieżce.