Korleis Apple VPN On Demand-domenereglar utløyser ein tunnel

Tunnelen opnar når du ber om eitt internt namn, og held seg lukka når den neste appen treng det like mykje. Det er ikkje ein feil i appen; det er forma på ein domeneregel. On-demand-konfigurasjonen til Apple skildrar vilkår for å opprette ei tilkopling, og domenforma av desse vilkåra spør resolvaren i systemet eit spørsmål før ein einaste pakke rører seg. To spørsmål blir stadig blanda saman: når tunnelen skal kome opp, og kva tunnelen ber når han først finst. Det første er ein utløysar, det andre er ein rute- og resolverpolicy, og ein profil set vanlegvis begge i same payload, og difor kan ein korrekt domeneregel framleis la deg bli verande på feil nettverk.

Utløysar og trafikkval ligg i ulike lag

Ein on-demand-regel bur i on-demand-ordboka til ein VPN-payload: ei ordna liste med reglar, kvar med ei handling og eit sett med matchvilkår. Systemet vurderer dei når tilkoplinga endrar seg eller når noko prøver å nå nettverket, og handlinga avgjer om tunnelen blir heva, vurdert, kopla frå eller ignorert. Alt dette skjer i nettverkslaget til plattforma, før appen din har ein socket.

Det som kjem etterpå, er ei eiga gruppe nøklar: IPv4- og IPv6-innstillingane til tunnelen, dei inkluderte og ekskluderte rutene, DNS-serveradressene og på iOS og iPadOS tilordninga per app som avgjer kva apper som i det heile får bruke tunnelen. Ein profil kan para ein brei utløysar med ei smal rute, eller ein smal utløysar med ei standardrute. Les berre den eine halvdelen, og den andre ser ut som ein funksjonsfeil.

Eg har ein laboratorieprofil som koplar til når som helst noko under eit internt domene blir spurt om, men berre ruter éi /16 inn i tunnelen. Han gjer nøyaktig det payloaden seier, og han er også den typen profil som genererer billettar: folk trur at ein tilkopla tunnel betyr at trafikken deira er inne i han.

Kva ein domeneregel eigentleg spør resolvaren om

Domenforma av regelen, ofte kalla connect-if-needed, granskar ikkje pakkepayloadar og overvakar ikkje URL-ar. Når eit namn blir løyst opp, samanliknar systemet det med domena i regelen og spør ved eit treff om namnet kan løysast opp gjennom DNS-serverane tunnelen tilbyr. Viss resolvaren til tunnelen svarar, blir namnet rekna som internt og tilkoplinga blir starta. Viss den lokale resolvaren svarar i staden, blir namnet handsama som eksternt og ingen tunnel dukkar opp. Oversynet til Apple over utrulling skildrar dette som nettverksdeteksjon etterfølgt av tilkoplingsvurdering.

To konsekvensar følgjer. Profilen må nemne DNS-serverar inne i tunnelen; ein domeneregel utan tunnelresolver har ingenting å samanlikne med, så vurderinga kan ikkje gi treffet du ventar. Og oppslaget må nå resolvaren i systemet. Ein app eller nettlesar som køyrer sin eigen krypterte DNS, ei utviding som svarar lokalt, eller ei tilkopling til ei bokstaveleg adresse gir aldri namneoppløysinga regelen venta på. Ein av dei lengste ettermiddagane eg har brukt, enda då eg oppdaga at klienten framfor tunnelen brukte DNS over HTTPS.

Bufring fjernar også utløysaren. Eit namn som allereie ligg i bufferen kan bli svara på utan sonden som ville ha starta tunnelen, så ein regel som verka i går, feilar etter ein omstart eller etter at tunnelen har vore oppe ei stund. På macOS nullstiller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder tilstanden; på iOS gir det å slå flymodus av og på eller starte eininga på nytt ei samanliknbar rein tavle.

Treffomfang: namn, apper og nettverk

Domenematching er éin type blant fleire. Ein regel kan også matche grensesnitttypen (Wi-Fi, mobil, Ethernet) og ein bestemt SSID, og oppføringar per app eller Safari-domene bind ein tunnel til éin arbeidsflyt. Den bindinga forklarer den merkelege opplevinga der berre éin app oppfører seg annleis enn alt anna: dei andre appane er utanfor omfanget til tunnelen, så dei held fram med å bruke den lokale vegen sjølv når tunnelikonet seier tilkopla.

Rekkjefølgja betyr meir enn folk ventar. Reglar blir vurderte i rekkjefølgje og den første som matchar gir handlinga, så ein brei kople-til-på-kva-som-helst-Wi-Fi-regel over ein smal domeneregel vinn stille og gjer domeneregelen utestbar. Før du skriv om domenelista, stadfest at ingen tidlegare regel allereie har matcha.

Difor er always-on ikkje berre ein strengare on-demand-regel. Handheving av always-on er ein eigen utrullingsmodus med eigne krav til overvaking og administrasjon; han held ein tunnel open i staden for å reagere på eit namn. Viss det du treng er ein tunnel som aldri fell, er ein domeneregel feil verktøy.

Feilmodusar som imiterer ein øydelagd regel

Dei fleste rapportane om at ein domeneregel ikkje verkar, hamnar på ein av fem stader, og berre den siste av dei er regelteksten.

Captive-portalar fortener si eiga line, fordi Wi-Fi på hotell og flyplassar fangar opp nettopp oppslaget regelen er avhengig av. Inntil portalen slepp eininga inn, er DNS-serveren til tunnelen utilgjengeleg, sonden feilar, og feilen ser ut som eit feilstava domene. Autentisering er det andre stille tilfellet: regelen kan utløysast, tunnelen kan byrje å kople til, og tilkoplinga døyr på eit utløpt sertifikat eller ein førespurnad som dukkar opp på ein annan skjerm.

IPv6 skaper ein variant som er lett å feildiagnostisere. Eit namn med begge adressefamiliane kan bli svara på først frå ein AAAA-post, medan rutelista til tunnelen berre ber IPv4. Éin nettlesar lukkast, ein annan feilar, og domenelista er heilt uskyldig.

Test med ein ekte førespurnad, i denne rekkjefølgja

Les policyen før du gissar. På macOS skriv sudo profiles show -type configuration ut installerte profilar inkludert VPN-payloaden, scutil --nc list viser tenestestatus, og scutil --nc show <service> skriv ut on-demand-ordboka systemet brukar. På ein administrert iPhone eller iPad kjem same payload frå administrasjonskonsollen eller ein MDM-rapport. Nettverksloggar er tilgjengelege med log stream --predicate 'subsystem == "com.apple.networkextension"' på macOS, og via einingskonsollen når telefonen er tilkopla.

Test deretter med eit vertsnamn som ikkje blei spurt om tidlegare i økta. Vel eit namn i DNS-sona til tunnelen som du veit blir løyst internt, be om det éin gong, og sjå om tunnelen dukkar opp. Køyr det same oppslaget to gonger: det andre forsøket trenar buffervegen, og skilnaden mellom dei to fortel deg om utløysaren er oppløysinga eller rutinga.

Når tunnelen er oppe, verifiser dei to laga separat. netstat -rn -f inet og netstat -rn -f inet6 viser kvar kvart prefiks peikar, scutil --dns viser resolverrekkjefølgja og kva grensesnitt som eig kvar resolver, og nettop -m route viser kva grensesnitt som bar byta. Viss tunnelen er oppe og resolvaren er riktig, men ressursen framleis feilar, slutt å redigere regelen; sjekk autorisasjon på serversida og returruta.

Når regelen tilhøyrer nokon andre

Viss tunnelen dukkar opp igjen etter at du kopla han frå, tilhøyrer regelen vanlegvis ein profil og ikkje ein app: ein konfigurasjon som er sendt ut via MDM, ein attverande personleg profil, eller ein profil installert av ein annan klient. sudo profiles show -type configuration pluss eit søk etter on-demand-nøklane vil snevre det inn, og fjerningsvegen er profilen, ikkje brytaren i menylinja. Sletting av tenesteposten eller appen etterlèt regelen, og neste installasjon arvar han igjen.

Éin test avgjer eigarskapet: kople frå, vent, be om det interne namnet igjen. Viss tunnelen kjem tilbake, verkar utløysaren som designa, og det opne spørsmålet er kven som administrerer han og om det omfanget er det du vil ha.

Før du melder dette som ein feil, gå gjennom dei same fem kontrollane: tunnelresolveradresser til stades i payloaden, eit namn som ikkje var bufra, ingen tidlegare regel som allereie matcha, ein AAAA-veg som rutelista dekkjer, og appen innanfor omfanget til tunnelen. Når alle fem held, gjer regelen jobben sin, og feilen ligg lenger framme i vegen.