Paano pinapagana ng domain rules ng Apple VPN On Demand ang isang tunnel

Bubukas ang tunnel kapag humiling ka ng isang panloob na pangalan at mananatiling sarado kapag ang susunod na app ay nangangailangan din nito nang husto. Hindi ito bug sa app; ito ang hugis ng isang domain rule. Inilalarawan ng on-demand configuration ng Apple ang mga kundisyon para makagawa ng koneksyon, at ang domain form ng mga kundisyong iyon ay nagtatanong sa resolver ng system bago pa gumalaw ang isang packet. Dalawang tanong ang palaging pinagsasama: kailan dapat umakyat ang tunnel, at ano ang dinadala ng tunnel kapag umiiral na ito. Ang una ay trigger, ang pangalawa ay patakaran ng ruta at resolver, at isang profile ang karaniwang nagtatakda ng dalawa sa parehong payload, kaya ang tamang domain rule ay maaari ka pa ring iwan sa maling network.

Ang trigger at pagpili ng trapiko ay nasa magkaibang layer

Ang on-demand rule ay nakatira sa on-demand dictionary ng isang VPN payload: isang nakaayos na listahan ng mga rule, bawat isa ay may aksyon at isang set ng match conditions. Sinusuri ng system ang mga ito kapag nagbago ang koneksyon o kapag may bagay na sumusubok na maabot ang network, at ang aksyon ang nagpapasya kung ang tunnel ay itataas, susuriin, ididiskonekta, o papansinin. Nangyayari ang lahat ng ito sa network layer ng platform, bago magkaroon ng socket ang app mo.

Ang sumusunod ay isang hiwalay na grupo ng mga key: ang IPv4 at IPv6 na setting ng tunnel, ang mga rutang kasama at hindi kasama, ang mga address ng DNS server, at sa iOS at iPadOS ang mapping per app na nagpapasya kung aling mga app ang maaaring gumamit ng tunnel. Maaaring ipares ng isang profile ang malawak na trigger sa makitid na ruta, o makitid na trigger sa default na ruta. Basahin lamang ang kalahati at ang kabila ay magmumukhang sira.

Mayroon akong laboratory profile na kumokonekta sa tuwing may hinihiling sa ilalim ng panloob na domain ngunit isang /16 lamang ang dinadaan sa tunnel. Ginagawa nito nang eksakto ang sinasabi ng payload nito, at ito rin ang uri ng profile na gumagawa ng mga ticket: ipinapalagay ng mga tao na ang konektadong tunnel ay nangangahulugang nasa loob nito ang kanilang trapiko.

Ano ang talagang itinatanong ng domain rule sa resolver

Ang domain form ng rule, na madalas tawaging connect-if-needed, ay hindi sinusuri ang packet payload at hindi nagmamatyag sa URL. Kapag naresolba ang isang pangalan, inihahambing ito ng system sa mga domain sa rule at, kung tumugma, nagtatanong kung maaaring iresolba ang pangalang iyon sa pamamagitan ng mga DNS server na ibinibigay ng tunnel. Kung sumagot ang resolver ng tunnel, itinuturing na panloob ang pangalan at nagsisimula ang koneksyon. Kung ang lokal na resolver ang sumagot, itinuturing na panlabas ang pangalan at walang tunnel na lumilitaw. Inilalarawan ng pangkalahatang-tanaw ng deployment ng Apple ito bilang pagtuklas ng network na sinusundan ng pagsusuri ng koneksyon.

Dalawang kahihinatnan ang sumusunod. Dapat pangalanan ng profile ang mga DNS server sa loob ng tunnel; ang domain rule na walang resolver ng tunnel ay walang maihahambing, kaya hindi maibibigay ng pagsusuri ang inaasahan mong tugma. At dapat maabot ng lookup ang resolver ng system. Ang app o browser na nagpapatakbo ng sarili nitong naka-encrypt na DNS, extension na sumasagot nang lokal, o koneksyon sa literal na address ay hindi kailanman gumagawa ng resolusyon ng pangalan na hinihintay ng rule. Ang isa sa pinakamahabang hapon na ginugol ko ay natapos nang matuklasan ko na ang client sa harap ng tunnel ay gumagamit ng DNS over HTTPS.

Inaalis din ng caching ang trigger. Ang pangalang nasa cache na ay maaaring sagutin nang walang probe na sana ang nagpatakbo ng tunnel, kaya ang rule na gumana kahapon ay nabigo pagkatapos ng reboot, o pagkatapos na tumagal ang tunnel. Sa macOS, nire-reset ng sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ang estado; sa iOS, ang pag-on at off ng airplane mode o pag-restart ng device ay nagbibigay ng maihahambing na malinis na simula.

Saklaw ng pagtutugma: mga pangalan, app, at network

Ang domain matching ay isang uri sa ilang uri. Ang isang rule ay maaari ring tumugma sa uri ng interface (Wi-Fi, cellular, Ethernet) at partikular na SSID, at ang mga entry per app o Safari domain ay nagbibigkis ng tunnel sa isang workflow. Ipinapaliwanag ng bigkis na iyon ang kakaibang karanasan kung saan isang app lamang ang kumikilos nang iba sa lahat: ang ibang mga app ay nasa labas ng saklaw ng tunnel, kaya patuloy silang gumagamit ng lokal na landas kahit sinasabi ng icon ng tunnel na konektado.

Mas mahalaga ang pagkakasunod-sunod kaysa inaasahan ng mga tao. Sinusuri ang mga rule nang sunud-sunod at ang unang tumutugma ang nagbibigay ng aksyon, kaya ang malawak na rule na kumonekta-sa-anumang-Wi-Fi na inilagay sa itaas ng makitid na domain rule ay tahimik na mananalo at gagawing hindi masusubok ang domain rule. Bago isulat muli ang listahan ng domain, tiyakin na wala pang naunang rule na tumugma.

Ito ang dahilan kung bakit ang always-on ay hindi lamang mas mahigpit na on-demand rule. Ang pagpapatupad ng always-on ay hiwalay na deployment mode na may sariling mga pangangailangan sa pangangasiwa at pamamahala; pinananatili nitong bukas ang tunnel sa halip na tumugon sa isang pangalan. Kung kailangan mo ng tunnel na hindi kailanman bumabagsak, maling tool ang domain rule.

Mga mode ng pagkasira na ginagaya ang sirang rule

Karamihan ng ulat na hindi gumagana ang domain rule ay napupunta sa isa sa limang lugar, at ang huli lamang sa mga iyon ang teksto ng rule.

Ang mga captive portal ay may sariling linya, dahil ang Wi-Fi sa hotel at airport ay humaharang sa mismong lookup na umaasa ang rule. Hanggang hindi pinapasok ng portal ang device, hindi maabot ang DNS server ng tunnel, nabigo ang probe, at ang pagkabigo ay mukhang maling baybay na domain. Ang authentication ay ang isa pang tahimik na kaso: maaaring mag-trigger ang rule, makapagsimulang kumonekta ang tunnel, at mamatay ang koneksyon sa expired na sertipiko o sa prompt na lumilitaw sa ibang display.

Ang IPv6 ay gumagawa ng variant na madaling maling masuri. Ang pangalang may dalawang address family ay maaaring sagutin muna mula sa AAAA record, habang ang listahan ng ruta ng tunnel ay nagdadala lamang ng IPv4. Isang browser ang nagtagumpay, isa ang nabigo, at ang listahan ng domain ay ganap na inosente.

Subukan gamit ang tunay na kahilingan, sa ganitong pagkakasunod-sunod

Basahin ang patakaran bago manghula. Sa macOS, ipiniprint ng sudo profiles show -type configuration ang mga naka-install na profile kasama ang VPN payload, ipinapakita ng scutil --nc list ang status ng serbisyo, at ipiniprint ng scutil --nc show <service> ang on-demand dictionary na ginagamit ng system. Sa managed na iPhone o iPad, ang parehong payload ay nagmumula sa management console o MDM report. Available ang network logs gamit ang log stream --predicate 'subsystem == "com.apple.networkextension"' sa macOS, at sa pamamagitan ng device console kapag nakakonekta ang telepono.

Pagkatapos, subukan gamit ang hostname na hindi pa tinanong nang mas maaga sa session. Pumili ng pangalan sa DNS zone ng tunnel na alam mong nagre-resolba nang panloob, hilingin ito nang isang beses, at panoorin kung lumilitaw ang tunnel. Patakbuhin ang parehong lookup nang dalawang beses: sinasanay ng ikalawang pagtatangka ang cache path, at ang pagkakaiba ng dalawa ay nagsasabi kung ang trigger ay ang resolusyon o ang routing.

Kapag umakyat na ang tunnel, i-verify ang dalawang layer nang hiwalay. Ipinapakita ng netstat -rn -f inet at netstat -rn -f inet6 kung saan naka-point ang bawat prefix, ipinapakita ng scutil --dns ang pagkakasunod-sunod ng resolver at kung aling interface ang nagmamay-ari ng bawat resolver, at ipinapakita ng nettop -m route kung aling interface ang nagdala ng bytes. Kung umakyat ang tunnel at tama ang resolver pero nabigo pa rin ang resource, itigil ang pag-edit ng rule; tingnan ang authorization sa server side at ang return route.

Kapag pag-aari ng iba ang rule

Kung muling lumitaw ang tunnel pagkatapos mong idiskonekta ito, karaniwang pag-aari ng profile ang rule at hindi ng app: configuration na itinulak sa pamamagitan ng MDM, natirang personal na profile, o profile na ininstalla ng ibang client. Ang sudo profiles show -type configuration at paghahanap sa on-demand keys ay magpapaliit nito, at ang landas ng pag-alis ay ang profile, hindi ang toggle sa menu bar. Kapag binura ang service entry o ang app, naiiwan ang rule, at namamana itong muli ng susunod na installation.

Isang pagsubok ang magpapasya sa pagmamay-ari: idiskonekta, maghintay, hilingin muli ang panloob na pangalan. Kung bumalik ang tunnel, gumagana ang trigger ayon sa disenyo at ang bukas na tanong ay kung sino ang namamahala nito at kung ang saklaw na iyon ang gusto mo.

Bago iulat ito bilang bug, daanan ang parehong limang pagsusuri: naroroon sa payload ang mga address ng resolver ng tunnel, pangalang hindi naka-cache, walang naunang rule na tumugma na, rutang AAAA na sakop ng listahan ng ruta, at ang app sa loob ng saklaw ng tunnel. Kapag nananatili ang lima, ginagawa ng rule ang trabaho nito at ang depekto ay mas malayo sa landas.