Jak doménová pravidla Apple VPN On Demand spouštějí tunel

Tunel se otevře, když požádáte o jeden interní název, a zůstane zavřený, když ho další aplikace potřebuje stejně nutně. To není chyba v aplikaci; je to podoba doménového pravidla. Konfigurace on-demand od Apple popisuje podmínky pro vytvoření připojení a doménová podoba těchto podmínek se ptá systémového resolveru na otázku dřív, než se pohne jediný paket. Neustále se pletou dvě otázky: kdy má tunel vstát a co tunel nese, když už existuje. První je spouštěč, druhá je politika tras a resolveru, a jeden profil obvykle nastavuje obojí ve stejném payloadu, proto vás správné doménové pravidlo může nechat ve špatné síti.

Spouštěč a výběr provozu leží v různých vrstvách

Pravidlo on-demand žije ve slovníku on-demand VPN payloadu: uspořádaný seznam pravidel, každé s akcí a sadou podmínek shody. Systém je vyhodnocuje, když se změní konektivita nebo když se něco snaží dosáhnout sítě, a akce rozhoduje, zda se tunel zvedne, vyhodnotí, odpojí nebo ignoruje. To vše se děje v síťové vrstvě platformy, dřív než vaše aplikace dostane socket.

To, co následuje, je samostatná skupina klíčů: nastavení IPv4 a IPv6 tunelu, jeho zahrnuté a vyloučené trasy, adresy DNS serverů a na iOS a iPadOS mapování podle aplikací, které rozhoduje, které aplikace vůbec smějí tunel používat. Profil může spárovat široký spouštěč s úzkou trasou nebo úzký spouštěč s výchozí trasou. Přečtěte jen jednu polovinu a druhá bude vypadat jako porucha.

Mám laboratorní profil, který se připojí, kdykoli se požaduje cokoli pod interní doménou, ale do tunelu směruje jen jednu /16. Dělá přesně to, co říká jeho payload, a je to také typ profilu, který generuje tikety: lidé předpokládají, že připojený tunel znamená, že jejich provoz je uvnitř.

Co doménové pravidlo skutečně ptá resolveru

Doménová podoba pravidla, často označovaná connect-if-needed, nezkoumá payloady paketů ani nesleduje URL. Když se název překládá, systém ho porovná s doménami v pravidle a při shodě se zeptá, zda lze tento název přeložit přes DNS servery, které tunel poskytuje. Pokud odpoví resolver tunelu, název se považuje za interní a připojení se zahájí. Pokud místo toho odpoví lokální resolver, název se považuje za externí a tunel se neobjeví. Přehled nasazení od Apple to popisuje jako detekci sítě následovanou vyhodnocením připojení.

Z toho plynou dva důsledky. Profil musí uvádět DNS servery uvnitř tunelu; doménové pravidlo bez resolveru tunelu nemá co porovnávat, takže vyhodnocení nemůže dát očekávanou shodu. A dotaz se musí dostat k systémovému resolveru. Aplikace nebo prohlížeč, který provozuje vlastní šifrované DNS, rozšíření, které odpovídá lokálně, nebo připojení k doslovné adrese nikdy nevytvoří překlad názvu, na který pravidlo čekalo. Jedno z nejdelších odpolední, která jsem strávil, skončilo, když jsem zjistil, že klient před tunelem používá DNS over HTTPS.

Kešování také odstraňuje spouštěč. Název už v keši může být zodpovězen bez sondy, která by tunel spustila, takže pravidlo, které včera fungovalo, selže po restartu nebo poté, co byl tunel chvíli nahoře. Na macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder resetuje stav; na iOS vám přepnutí letového režimu nebo restart zařízení dá srovnatelný čistý stav.

Rozsah shody: názvy, aplikace a sítě

Doménová shoda je jeden typ z několika. Pravidlo může odpovídat i typu rozhraní (Wi-Fi, mobilní, Ethernet) a konkrétnímu SSID a položky podle aplikace nebo domény Safari vážou tunel na jeden pracovní postup. Tato vazba vysvětluje podivnou zkušenost, kdy se jen jedna aplikace chová jinak než všechno ostatní: ostatní aplikace jsou mimo rozsah tunelu, takže dál používají lokální cestu, i když ikona tunelu hlásí připojeno.

Pořadí je důležitější, než lidé čekají. Pravidla se vyhodnocují postupně a první shoda dodá akci, takže široké pravidlo připojit se na jakékoli Wi-Fi umístěné nad úzkým doménovým pravidlem tiše vyhraje a udělá doménové pravidlo netestovatelným. Než přepíšete seznam domén, potvrďte, že žádné dřívější pravidlo už neodpovídalo.

To je také důvod, proč always-on není jen přísnější pravidlo on-demand. Vynucení always-on je samostatný režim nasazení s vlastními požadavky na dohled a správu; drží tunel otevřený, místo aby reagovalo na název. Pokud potřebujete tunel, který nikdy nespadne, je doménové pravidlo špatný nástroj.

Režimy selhání, které napodobují rozbité pravidlo

Většina hlášení, že doménové pravidlo nefunguje, spadá na jedno z pěti míst a jen to poslední je text pravidla.

Captive portály si zaslouží vlastní řádek, protože Wi-Fi v hotelích a na letištích zachytává právě to vyhledávání, na kterém pravidlo závisí. Dokud portál zařízení nepustí, je DNS server tunelu nedostupný, sonda selže a selhání vypadá jako překlep v doméně. Autentizace je druhý tichý případ: pravidlo může vystřelit, tunel může začít spojovat a spojení umře na propadlém certifikátu nebo na výzvě, která se objeví na jiném displeji.

IPv6 vytváří variantu, kterou lze snadno špatně diagnostikovat. Název s oběma rodinami adres může být nejprve zodpovězen z AAAA záznamu, zatímco seznam tras tunelu nese jen IPv4. Jeden prohlížeč uspěje, jiný selže a seznam domén je zcela nevinný.

Testujte skutečným požadavkem, v tomto pořadí

Přečtěte si politiku, než budete hádat. Na macOS sudo profiles show -type configuration vypíše nainstalované profily včetně VPN payloadu, scutil --nc list ukáže stav služby a scutil --nc show <service> vypíše slovník on-demand, který systém používá. Na spravovaném iPhonu nebo iPadu přichází stejný payload z konzole správy nebo z hlášení MDM. Síťové protokoly jsou k dispozici s log stream --predicate 'subsystem == "com.apple.networkextension"' na macOS a přes konzoli zařízení, když je telefon připojen.

Potom testujte s názvem hostitele, který v této relaci ještě nebyl dotazován. Vyberte název v DNS zóně tunelu, o kterém víte, že se překládá interně, jednou ho vyžádejte a sledujte, zda se tunel objeví. Spusťte stejné vyhledávání dvakrát: druhý pokus procvičí cestu přes keš a rozdíl mezi nimi vám řekne, zda je spouštěčem překlad, nebo směrování.

Po zvednutí tunelu ověřte obě vrstvy odděleně. netstat -rn -f inet a netstat -rn -f inet6 ukazují, kam každý prefix míří, scutil --dns ukazuje pořadí resolverů a které rozhraní vlastní který resolver, a nettop -m route ukazuje, které rozhraní přeneslo bajty. Pokud je tunel nahoře a resolver správný, ale zdroj stále selhává, přestaňte pravidlo upravovat; zkontrolujte autorizaci na straně serveru a zpáteční trasu.

Když pravidlo patří někomu jinému

Pokud se tunel po odpojení znovu objeví, pravidlo obvykle patří profilu, ne aplikaci: konfigurace vynucená přes MDM, zbylý osobní profil nebo profil nainstalovaný jiným klientem. sudo profiles show -type configuration plus hledání klíčů on-demand to zúží a cestou odstranění je profil, ne přepínač v řádku nabídek. Smazání položky služby nebo aplikace pravidlo zanechá a další instalace ho znovu zdědí.

Jeden test rozhodne o vlastnictví: odpojte, počkejte, znovu vyžádejte interní název. Pokud se tunel vrátí, spouštěč funguje podle návrhu a otevřenou otázkou je, kdo ho spravuje a zda je tento rozsah ten, který chcete.

Než to nahlásíte jako chybu, projděte stejných pět kontrol: adresy resolveru tunelu přítomné v payloadu, název, který nebyl v keši, žádné dřívější pravidlo, které už odpovídalo, cesta AAAA, kterou seznam tras pokrývá, a aplikace v rozsahu tunelu. Když všech pět platí, pravidlo dělá svou práci a chyba je někde dál po cestě.