Ako doménové pravidlá Apple VPN On Demand spúšťajú tunel

Tunel sa otvorí, keď požiadate o jedno interné meno, a zostane zavretý, keď ho ďalšia aplikácia potrebuje rovnako naliehavo. To nie je chyba v aplikácii; je to podoba doménového pravidla. Konfigurácia on-demand od Apple opisuje podmienky na vytvorenie spojenia a doménová podoba týchto podmienok sa pýta systémového resolvera na otázku skôr, než sa pohne jediný paket. Neustále sa zamieňajú dve otázky: kedy má tunel vstať a čo tunel nesie, keď už existuje. Prvá je spúšťač, druhá je politika trás a resolvera, a jeden profil zvyčajne nastavuje oboje v tom istom payloade, preto vás správne doménové pravidlo môže nechať v nesprávnej sieti.

Spúšťač a výber prevádzky ležia v rôznych vrstvách

Pravidlo on-demand žije v slovníku on-demand VPN payloadu: usporiadaný zoznam pravidiel, každé s akciou a množinou podmienok zhody. Systém ich vyhodnocuje, keď sa zmení konektivita alebo keď sa niečo snaží dosiahnuť sieť, a akcia rozhoduje, či sa tunel zdvihne, vyhodnotí, odpojí alebo ignoruje. To všetko sa deje v sieťovej vrstve platformy, skôr než vaša aplikácia dostane socket.

To, čo nasleduje, je samostatná skupina kľúčov: nastavenia IPv4 a IPv6 tunela, jeho zahrnuté a vylúčené trasy, adresy DNS serverov a na iOS a iPadOS mapovanie podľa aplikácie, ktoré rozhoduje, ktoré aplikácie vôbec smú tunel používať. Profil môže spárovať široký spúšťač s úzkou trasou alebo úzky spúšťač s predvolenou trasou. Prečítajte len jednu polovicu a druhá bude vyzerať ako porucha.

Mám laboratórny profil, ktorý sa pripojí vždy, keď sa požaduje čokoľvek pod internou doménou, ale do tunela smeruje len jednu /16. Robí presne to, čo hovorí jeho payload, a je to aj typ profilu, ktorý generuje tikety: ľudia predpokladajú, že pripojený tunel znamená, že ich prevádzka je v ňom.

Čo doménové pravidlo skutočne pýta resolvera

Doménová podoba pravidla, často nazývaná connect-if-needed, neskúma payloady paketov ani nesleduje URL. Keď sa meno prekladá, systém ho porovná s doménami v pravidle a pri zhode sa spýta, či sa toto meno dá preložiť cez DNS servery, ktoré tunel poskytuje. Ak odpovie resolver tunela, meno sa považuje za interné a spojenie sa začne. Ak namiesto toho odpovie lokálny resolver, meno sa považuje za externé a tunel sa neobjaví. Prehľad nasadenia od Apple to opisuje ako detekciu siete nasledovanú vyhodnotením spojenia.

Vyplývajú z toho dva dôsledky. Profil musí uviesť DNS servery vnútri tunela; doménové pravidlo bez resolvera tunela nemá čo porovnávať, takže vyhodnotenie nemôže dať očakávanú zhodu. A dopyt sa musí dostať k systémovému resolveru. Aplikácia alebo prehliadač, ktorý prevádzkuje vlastné šifrované DNS, rozšírenie, ktoré odpovedá lokálne, alebo spojenie s doslovnou adresou nikdy nevytvoria preklad mena, na ktorý pravidlo čakalo. Jedno z najdlhších popoludní, ktoré som strávil, sa skončilo, keď som zistil, že klient pred tunelom používal DNS over HTTPS.

Aj kešovanie odstraňuje spúšťač. Meno už v keši môže byť zodpovedané bez sondy, ktorá by tunel spustila, takže pravidlo, ktoré včera fungovalo, zlyhá po reštarte alebo po tom, čo bol tunel chvíľu hore. Na macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder resetuje stav; na iOS vám prepnutie leteckého režimu alebo reštart zariadenia dá porovnateľný čistý stav.

Rozsah zhody: mená, aplikácie a siete

Doménová zhoda je jeden typ z viacerých. Pravidlo môže zodpovedať aj typu rozhrania (Wi-Fi, mobilné, Ethernet) a konkrétnemu SSID a položky podľa aplikácie alebo domény Safari viažu tunel na jeden pracovný postup. Táto väzba vysvetľuje zvláštnu skúsenosť, keď sa len jedna aplikácia správa inak ako všetko ostatné: ostatné aplikácie sú mimo rozsahu tunela, takže ďalej používajú lokálnu cestu, aj keď ikona tunela hlási pripojené.

Poradie je dôležitejšie, než ľudia čakajú. Pravidlá sa vyhodnocujú postupne a prvá zhoda dodá akciu, takže široké pravidlo pripojiť sa na akúkoľvek Wi-Fi umiestnené nad úzkym doménovým pravidlom ticho vyhrá a urobí doménové pravidlo netestovateľným. Pred prepísaním zoznamu domén potvrďte, že žiadne skoršie pravidlo už neodpovedalo.

Preto always-on nie je len prísnejšie pravidlo on-demand. Vynútenie always-on je samostatný režim nasadenia s vlastnými požiadavkami na dohľad a správu; drží tunel otvorený namiesto toho, aby reagoval na meno. Ak potrebujete tunel, ktorý nikdy nespadne, doménové pravidlo je nesprávny nástroj.

Režimy zlyhania, ktoré napodobňujú pokazené pravidlo

Väčšina hlásení, že doménové pravidlo nefunguje, padá na jedno z piatich miest, a len to posledné je text pravidla.

Captive portály si zaslúžia vlastný riadok, pretože Wi-Fi v hoteloch a na letiskách zachytáva práve ten dopyt, od ktorého pravidlo závisí. Kým portál nepustí zariadenie, DNS server tunela je nedostupný, sonda zlyhá a zlyhanie vyzerá ako nesprávne napísaná doména. Autentifikácia je druhý tichý prípad: pravidlo môže vystreliť, tunel môže začať spájať a spojenie zomrie na expirovanom certifikáte alebo na výzve, ktorá sa objaví na inom displeji.

IPv6 vytvára variant, ktorý sa dá ľahko nesprávne diagnostikovať. Menu s oboma rodinami adries môže byť najprv zodpovedané z AAAA záznamu, zatiaľ čo zoznam trás tunela nesie len IPv4. Jeden prehliadač uspeje, druhý zlyhá a zoznam domén je úplne nevinný.

Testujte skutočným dopytom, v tomto poradí

Prečítajte si politiku, kým začnete hádať. Na macOS sudo profiles show -type configuration vypíše nainštalované profily vrátane VPN payloadu, scutil --nc list ukáže stav služby a scutil --nc show <service> vypíše slovník on-demand, ktorý systém používa. Na spravovanom iPhone alebo iPad prichádza rovnaký payload z konzoly správy alebo z hlásenia MDM. Sieťové záznamy sú dostupné s log stream --predicate 'subsystem == "com.apple.networkextension"' na macOS a cez konzolu zariadenia, keď je telefón pripojený.

Potom testujte s názvom hostiteľa, ktorý v tejto relácii ešte nebol dotazovaný. Vyberte meno v DNS zóne tunela, o ktorom viete, že sa prekladá interne, požiadajte oň raz a sledujte, či sa tunel objaví. Spustite ten istý dopyt dvakrát: druhý pokus precvičí cestu cez keš a rozdiel medzi nimi vám povie, či je spúšťačom preklad alebo smerovanie.

Po zdvihnutí tunela overte obe vrstvy oddelene. netstat -rn -f inet a netstat -rn -f inet6 ukazujú, kam každý prefix smeruje, scutil --dns ukazuje poradie resolverov a ktoré rozhranie vlastní ktorý resolver, a nettop -m route ukazuje, ktoré rozhranie prenieslo bajty. Ak je tunel hore a resolver správny, ale zdroj stále zlyháva, prestaňte upravovať pravidlo; skontrolujte autorizáciu na strane servera a spiatočnú trasu.

Keď pravidlo patrí niekomu inému

Ak sa tunel po odpojení znova objaví, pravidlo zvyčajne patrí profilu, nie aplikácii: konfigurácia vytlačená cez MDM, zvyšný osobný profil alebo profil nainštalovaný iným klientom. sudo profiles show -type configuration plus hľadanie kľúčov on-demand to zúži a cestou odstránenia je profil, nie prepínač v riadku ponuky. Vymazanie položky služby alebo aplikácie pravidlo zanechá a ďalšia inštalácia ho znova zdedí.

Jeden test rozhodne o vlastníctve: odpojte, počkajte, znova požiadajte o interné meno. Ak sa tunel vráti, spúšťač funguje podľa návrhu a otvorenou otázkou je, kto ho spravuje a či je ten rozsah ten, ktorý chcete.

Pred nahlásením tohto ako chyby prejdite tých istých päť kontrol: adresy resolvera tunela prítomné v payloade, meno, ktoré nebolo v keši, žiadne skoršie pravidlo, ktoré už zodpovedalo, cesta AAAA, ktorú zoznam trás pokrýva, a aplikácia v rozsahu tunela. Keď všetkých päť platí, pravidlo robí svoju prácu a chyba je ďalej po ceste.