Kiel domajnaj reguloj de Apple VPN On Demand malfermas tunelon

La tunelo malfermiĝas, kiam vi petas unu internan nomon, kaj restas fermita, kiam la sekva aplikaĵo bezonas ĝin same urĝe. Tio ne estas cimo en la aplikaĵo; ĝi estas la formo de domajna regulo. La agordo on-demand de Apple priskribas kondiĉojn por fari konekton, kaj la domajna formo de tiuj kondiĉoj demandas la sistemresolvilon antaŭ ol eĉ unu pakaĵo moviĝas. Du demandoj konstante konfuziĝas: kiam la tunelo devus leviĝi, kaj kion la tunelo portas post kiam ĝi ekzistas. La unua estas ekigilo, la dua estas politiko de vojoj kaj resolvilo, kaj unu profilo kutime agordas ambaŭ en la sama payload, tial ĝusta domajna regulo ankoraŭ povas lasi vin en la malĝusta reto.

Ekigilo kaj trafika elekto situas en malsamaj tavoloj

Regulo on-demand loĝas en la vortaro on-demand de VPN-payload: ordigita listo de reguloj, ĉiu kun ago kaj aro da kongruaj kondiĉoj. La sistemo taksas ilin, kiam konekteco ŝanĝiĝas aŭ kiam io provas atingi la reton, kaj la ago decidas ĉu la tunelo leviĝas, taksiĝas, malkonektiĝas aŭ estas ignorata. Ĉio tio okazas en la reta tavolo de la platformo, antaŭ ol via aplikaĵo havas ingon.

Tio, kio sekvas, estas aparta grupo de ŝlosiloj: la agordoj IPv4 kaj IPv6 de la tunelo, ĝiaj inkluzivitaj kaj ekskluzivitaj vojoj, ĝiaj DNS-servilaj adresoj, kaj en iOS kaj iPadOS la mapado laŭ aplikaĵo, kiu decidas, kiuj aplikaĵoj rajtas uzi la tunelon. Profilo povas pariĝi larĝan ekigilon kun mallarĝa vojo, aŭ mallarĝan ekigilon kun defaŭlta vojo. Legu nur unu duonon kaj la alia aspektos kiel misfunkcio.

Mi tenas laboratorian profilon, kiu konektiĝas kiam ajn io sub interna domajno estas petata, sed enkursigas nur unu /16 en la tunelon. Ĝi faras ĝuste tion, kion diras ĝia payload, kaj ĝi ankaŭ estas la speco de profilo, kiu generas biletojn: homoj supozas, ke konektita tunelo signifas, ke ilia trafiko estas ene de ĝi.

Kion domajna regulo vere demandas la resolvilon

La domajna formo de la regulo, ofte nomata connect-if-needed, ne ekzamenas pakaĵajn payloadojn nek observas URL-ojn. Kiam nomo estas solvata, la sistemo komparas ĝin kun la domajnoj en la regulo kaj, ĉe kongruo, demandas ĉu tiu nomo solveblas per la DNS-serviloj, kiujn la tunelo provizas. Se la resolvilo de la tunelo respondas, la nomo validas kiel interna kaj la konekto komenciĝas. Se anstataŭe respondas la loka resolvilo, la nomo traktiĝas kiel ekstera kaj neniu tunelo aperas. La superrigardo pri enkonduko de Apple priskribas tion kiel retan detekton sekvatan de konekta takso.

Du sekvoj sekvas. La profilo devas nomi DNS-servilojn ene de la tunelo; domajna regulo sen tunela resolvilo havas nenion por kompari, do la takso ne povas produkti la atendatan kongruon. Kaj la serĉo devas atingi la sistemresolvilon. Aplikaĵo aŭ retumilo, kiu funkciigas sian propran ĉifritan DNS, etendaĵo, kiu respondas loke, aŭ konekto al laŭvorta adreso neniam produktas la nomsolevon, kiun la regulo atendis. Unu el la plej longaj posttagmezoj, kiujn mi pasigis, finiĝis, kiam mi malkovris, ke la kliento antaŭ la tunelo uzis DNS over HTTPS.

Kaŝmemoro ankaŭ forigas la ekigilon. Nomo jam en la kaŝmemoro povas esti respondita sen la sondado, kiu estus lanĉinta la tunelon, do regulo, kiu funkciis hieraŭ, malsukcesas post restartigo aŭ post kiam la tunelo estis supre dum tempo. En macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder restarigas la staton; en iOS ŝalti kaj malŝalti aviadan reĝimon aŭ restartigi la aparaton donas al vi kompareblan puran staton.

Kongrua amplekso: nomoj, aplikaĵoj kaj retoj

Domajna kongruo estas unu tipo inter pluraj. Regulo ankaŭ povas kongrui la interfacan tipon (Wi-Fi, poŝtelefona, Ethernet) kaj specifan SSID, kaj rikordoj laŭ aplikaĵo aŭ Safari-domajno ligas tunelon al unu laborfluo. Tiu ligo klarigas la strangan sperton, kie nur unu aplikaĵo kondutas alie ol ĉio alia: la aliaj aplikaĵoj estas ekster la amplekso de la tunelo, do ili daŭre uzas la lokan vojon eĉ kiam la tunela ikono diras konektita.

Ordo gravas pli, ol homoj atendas. Reguloj taksiĝas sinsekve kaj la unua kongrua provizas la agon, do larĝa regulo konekti-ĉe-ajna-Wi-Fi metita super mallarĝa domajna regulo silente venkos kaj igos la domajnan regulon netestebla. Antaŭ ol vi reverkos la domajnan liston, konfirmu, ke neniu pli frua regulo jam kongruis.

Tial always-on ne estas nur pli strikta on-demand regulo. La devigo de always-on estas aparta enkonduka reĝimo kun propraj postuloj pri superrigardo kaj administrado; ĝi tenas tunelon malfermita anstataŭ reagi al nomo. Se vi bezonas tunelon, kiu neniam falas, domajna regulo estas la malĝusta ilo.

Malsukcesaj reĝimoj, kiuj imitas rompitan regulon

Plej multaj raportoj, ke domajna regulo ne funkcias, falas en unu el kvin lokoj, kaj nur la lasta el ili estas la teksto de la regulo.

Captive-pordegoj meritas sian propran linion, ĉar hotelaj kaj flughavenaj Wi-Fi-retaj interkaptas ĝuste tiun serĉon, de kiu la regulo dependas. Ĝis la pordego enlasas la aparaton, la DNS-servilo de la tunelo estas neatingebla, la sondado malsukcesas, kaj la malsukceso aspektas kiel mise literumita domajno. Aŭtentigo estas la alia silenta kazo: la regulo povas ekfunkcii, la tunelo povas komenci konekti, kaj la konekto mortas ĉe eksdata atestilo aŭ ĉe prompto, kiu aperas sur alia ekrano.

IPv6 kreas varianton, kiun oni facile misdiagnozas. Nomo kun ambaŭ adresfamilioj povas esti respondita unue el AAAA-rikordo, dum la voja listo de la tunelo portas nur IPv4. Unu retumilo sukcesas, alia malsukcesas, kaj la domajna listo estas tute senkulpa.

Testu per reala peto, en ĉi tiu ordo

Legu la politikon antaŭ ol diveni. En macOS sudo profiles show -type configuration presas instalitajn profilon inkluzive de la VPN-payload, scutil --nc list montras la servostaton, kaj scutil --nc show <service> presas la vortaron on-demand, kiun la sistemo uzas. En kontrolata iPhone aŭ iPad la sama payload venas el la administra konzolo aŭ el MDM-raporto. Retaj protokoloj disponeblas per log stream --predicate 'subsystem == "com.apple.networkextension"' en macOS, kaj per la aparata konzolo, kiam la telefono estas konektita.

Poste testu per gastiga nomo, kiu ne estis demandita pli frue en la seanco. Elektu nomon en la DNS-zono de la tunelo, pri kiu vi scias, ke ĝi solviĝas interne, petu ĝin unufoje, kaj observu, ĉu la tunelo aperas. Rulu la saman serĉon dufoje: la dua provo ekzercas la kaŝmemoran vojon, kaj la diferenco inter la du diras al vi, ĉu la ekigilo estas la solvo aŭ la enkursigo.

Post kiam la tunelo estas supre, kontrolu la du tavolojn aparte. netstat -rn -f inet kaj netstat -rn -f inet6 montras, kien ĉiu prefikso montras, scutil --dns montras la ordon de resolviloj kaj kiu interfaco posedas ĉiun resolvilon, kaj nettop -m route montras, kiu interfaco portis la bajtojn. Se la tunelo estas supre kaj la resolvilo ĝustas sed la rimedo ankoraŭ malsukcesas, ĉesu redakti la regulon; kontrolu servilflankan rajtigon kaj la revenan vojon.

Kiam la regulo apartenas al iu alia

Se la tunelo reaperas post kiam vi malkonektis ĝin, la regulo kutime apartenas al profilo, ne al aplikaĵo: agordo puŝita per MDM, restinta persona profilo, aŭ profilo instalita de alia kliento. sudo profiles show -type configuration plus serĉo pri la on-demand ŝlosiloj mallarĝigos ĝin, kaj la foriga vojo estas la profilo, ne la ŝaltilo en la menuo. Forigi la servan rikordon aŭ la aplikaĵon lasas la regulon malantaŭe, kaj la sekva instalado denove heredas ĝin.

Unu testo decidas posedon: malkonektu, atendu, petu la internan nomon denove. Se la tunelo revenas, la ekigilo funkcias laŭ la dezajno kaj la malferma demando estas, kiu administras ĝin kaj ĉu tiu amplekso estas tio, kion vi volas.

Antaŭ ol raporti ĉi tion kiel cimon, trapasu la samajn kvin kontrolojn: tunelaj resolvilaj adresoj ĉeestas en la payload, nomo, kiu ne estis kaŝmemorigita, neniu pli frua regulo jam kongruis, AAAA-vojo, kiun la voja listo kovras, kaj la aplikaĵo ene de la amplekso de la tunelo. Kiam ĉiuj kvin validas, la regulo faras sian taskon kaj la kulpo estas pli antaŭe laŭ la vojo.