Kako domenska pravila Apple VPN On Demand zaženejo tunel

Tunel se odpre, ko zahtevate eno notranje ime, in ostane zaprt, ko ga naslednja aplikacija potrebuje prav tako nujno. To ni napaka v aplikaciji; to je oblika domenskega pravila. Appleova konfiguracija on-demand opisuje pogoje za vzpostavitev povezave, in domenska oblika teh pogojev vpraša sistemski resolver vprašanje, preden se premakne en sam paket. Dve vprašanji se nenehno zamenjujeta: kdaj naj se tunel dvigne in kaj tunel nosi, ko že obstaja. Prvo je sprožilec, drugo je politika poti in resolverja, in en profil običajno nastavi oboje v istem payloadu, zato vas pravilno domensko pravilo lahko še vedno pusti v napačnem omrežju.

Sprožilec in izbira prometa ležita v različnih plasteh

Pravilo on-demand živi v slovarju on-demand VPN payloada: urejen seznam pravil, vsako z dejanjem in nizom pogojev ujemanja. Sistem jih ocenjuje, ko se povezljivost spremeni ali ko poskuša nekaj doseči omrežje, in dejanje odloči, ali se tunel dvigne, oceni, prekine ali prezre. Vse to se dogaja v omrežni plasti platforme, preden ima vaša aplikacija socket.

Kar sledi, je ločena skupina ključev: nastavitve IPv4 in IPv6 tunela, njegove vključene in izključene poti, naslovi strežnikov DNS in na iOS ter iPadOS preslikava po aplikacijah, ki odloči, katere aplikacije sploh smejo uporabljati tunel. Profil lahko seznani širok sprožilec z ozko potjo ali ozek sprožilec s privzeto potjo. Preberite samo eno polovico in druga bo videti kot okvara.

Imam laboratorijski profil, ki se poveže vsakič, ko je zahtevano karkoli pod notranjo domeno, a v tunel usmeri le eno /16. Počne točno to, kar piše v njegovem payloadu, in je tudi vrsta profila, ki ustvarja zahtevke: ljudje domnevajo, da povezan tunel pomeni, da je njihov promet v njem.

Kaj domensko pravilo zares vpraša resolver

Domenska oblika pravila, pogosto imenovana connect-if-needed, ne pregleduje payloadov paketov in ne opazuje URL-jev. Ko se ime razreši, ga sistem primerja z domenami v pravilu in ob ujemanju vpraša, ali je to ime mogoče razrešiti prek strežnikov DNS, ki jih ponuja tunel. Če odgovori resolver tunela, ime velja za notranje in povezava se začne. Če namesto tega odgovori lokalni resolver, se ime obravnava kot zunanje in tunel se ne pojavi. Appleov pregled uvajanja to opisuje kot zaznavanje omrežja, ki mu sledi ocena povezave.

Iz tega sledita dve posledici. Profil mora navesti strežnike DNS znotraj tunela; domensko pravilo brez resolverja tunela nima česa primerjati, zato ocena ne more dati pričakovanega ujemanja. In poizvedba mora doseči sistemski resolver. Aplikacija ali brskalnik, ki poganja lasten šifriran DNS, razširitev, ki odgovarja lokalno, ali povezava z dobesednim naslovom nikoli ne ustvarijo razrešitve imena, na katero je pravilo čakalo. Eno najdaljših popoldnevov, ki sem jih preživel, se je končalo, ko sem odkril, da odjemalec pred tunelom uporablja DNS over HTTPS.

Tudi predpomnjenje odstrani sprožilec. Ime, ki je že v predpomnilniku, je lahko odgovorjeno brez sonde, ki bi zagnala tunel, zato pravilo, ki je delovalo včeraj, odpove po ponovnem zagonu ali potem, ko je bil tunel nekaj časa gor. V macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ponastavi stanje; v iOS preklop letalskega načina ali ponovni zagon naprave da primerljiv čist začetek.

Obseg ujemanja: imena, aplikacije in omrežja

Ujemanje domene je ena vrsta med več. Pravilo se lahko ujema tudi z vrsto vmesnika (Wi-Fi, mobilni, Ethernet) in določenim SSID-om, vnosi po aplikaciji ali domeni Safari pa vežejo tunel na en delovni tok. Ta vez pojasnjuje nenavadno izkušnjo, ko se samo ena aplikacija obnaša drugače kot vse ostalo: druge aplikacije so zunaj obsega tunela, zato še naprej uporabljajo lokalno pot, tudi ko ikona tunela pravi povezano.

Vrstni red je pomembnejši, kot ljudje pričakujejo. Pravila se ocenjujejo po vrsti in prvo ujemanje poda dejanje, zato široko pravilo poveži-se-na-katero-koli-Wi-Fi, postavljeno nad ozko domensko pravilo, tiho zmaga in naredi domensko pravilo netestljivo. Preden prepišete seznam domen, potrdite, da se nobeno prejšnje pravilo ni že ujemalo.

Zato always-on ni le strožje pravilo on-demand. Uveljavljanje always-on je ločen način uvajanja z lastnimi zahtevami po nadzoru in upravljanju; drži tunel odprt, namesto da bi se odzival na ime. Če potrebujete tunel, ki nikoli ne pade, je domensko pravilo napačno orodje.

Načini okvare, ki posnemajo pokvarjeno pravilo

Večina poročil, da domensko pravilo ne deluje, pade na eno od petih mest, in samo zadnje od njih je besedilo pravila.

Captive portali si zaslužijo svojo vrstico, ker Wi-Fi v hotelih in na letališčih prestreže prav tisto poizvedbo, od katere je odvisno pravilo. Dokler portal ne spusti naprave, je strežnik DNS tunela nedosegljiv, sonda odpove in okvara je videti kot napačno črkovana domena. Preverjanje pristnosti je drugi tihi primer: pravilo se lahko sproži, tunel se lahko začne povezovati in povezava umre na poteklem certifikatu ali na pozivu, ki se pojavi na drugem zaslonu.

IPv6 ustvari različico, ki jo je lahko napačno diagnosticirati. Imenu z obema družinama naslovov je lahko najprej odgovorjeno iz zapisa AAAA, medtem ko seznam poti tunela nosi le IPv4. En brskalnik uspe, drugi ne, in seznam domen je popolnoma nedolžen.

Preizkusite z resnično zahtevo, v tem vrstnem redu

Preberite politiko, preden ugibate. V macOS sudo profiles show -type configuration izpiše nameščene profile vključno s payloadom VPN, scutil --nc list pokaže stanje storitve in scutil --nc show <service> izpiše slovar on-demand, ki ga uporablja sistem. Na upravljanem iPhoneu ali iPadu pride isti payload iz konzole za upravljanje ali poročila MDM. Omrežni dnevniki so na voljo z log stream --predicate 'subsystem == "com.apple.networkextension"' v macOS in prek konzole naprave, ko je telefon priključen.

Nato preizkusite z imenom gostitelja, po katerem v tej seji še ni bilo povpraševanja. Izberite ime v območju DNS tunela, za katero veste, da se razreši notranje, zahtevajte ga enkrat in opazujte, ali se tunel pojavi. Zaženite isto poizvedbo dvakrat: drugi poskus vadi pot predpomnilnika, in razlika med njima vam pove, ali je sprožilec razrešitev ali usmerjanje.

Ko je tunel dvignjen, preverite obe plasti ločeno. netstat -rn -f inet in netstat -rn -f inet6 kažeta, kam vodi vsak predpona, scutil --dns kaže vrstni red resolverjev in kateri vmesnik ima kateri resolver, nettop -m route pa kaže, kateri vmesnik je prenesel bajte. Če je tunel dvignjen in je resolver pravilen, a vir še vedno odpove, prenehajte urejati pravilo; preverite avtorizacijo na strani strežnika in povratno pot.

Ko pravilo pripada nekomu drugemu

Če se tunel po odklopu znova pojavi, pravilo običajno pripada profilu in ne aplikaciji: konfiguracija, potisnjena prek MDM, preostali osebni profil ali profil, ki ga je namestil drug odjemalec. sudo profiles show -type configuration in iskanje ključev on-demand to zoži, in pot odstranitve je profil, ne stikalo v menijski vrstici. Brisanje vnosa storitve ali aplikacije pusti pravilo za seboj, in naslednja namestitev ga spet podeduje.

En preizkus odloči o lastništvu: odklopite, počakajte, znova zahtevajte notranje ime. Če se tunel vrne, sprožilec deluje po načrtu in odprto vprašanje je, kdo ga upravlja in ali je ta obseg tisti, ki ga želite.

Preden to prijavite kot napako, pojdite skozi istih pet preverjanj: naslovi resolverja tunela prisotni v payloadu, ime, ki ni bilo v predpomnilniku, nobeno prejšnje pravilo, ki se je že ujemalo, pot AAAA, ki jo pokriva seznam poti, in aplikacija v obsegu tunela. Ko vseh pet drži, pravilo opravlja svoje delo, napaka pa je dlje po poti.