Slik utløser Apples VPN On Demand-domeneregler en tunnel

Tunnelen åpner når du ber om ett internt navn, og holder seg lukket når den neste appen trenger det like mye. Det er ikke en feil i appen; det er formen på en domeneregel. Apples on-demand-konfigurasjon beskriver betingelser for å opprette en forbindelse, og domenformen av disse betingelsene spør systemets resolver et spørsmål før én eneste pakke beveger seg. To spørsmål blandes hele tiden: når tunnelen skal komme opp, og hva tunnelen bærer når den først finnes. Det første er en utløser, det andre er en rute- og resolverpolitikk, og én profil setter vanligvis begge i samme payload, og derfor kan en korrekt domeneregel likevel etterlate deg på feil nettverk.

Utløser og trafikkvalg ligger i forskjellige lag

En on-demand-regel bor i on-demand-ordboken til en VPN-payload: en ordnet liste med regler, hver med en handling og et sett med matchbetingelser. Systemet vurderer dem når tilkoblingen endres eller når noe prøver å nå nettverket, og handlingen avgjør om tunnelen heves, vurderes, kobles fra eller ignoreres. Alt dette skjer i plattformens nettverkslag, før appen din har en socket.

Det som følger, er en egen gruppe nøkler: tunnelens IPv4- og IPv6-innstillinger, de inkluderte og ekskluderte rutene, DNS-serveradressene og på iOS og iPadOS tilordningen per app som avgjør hvilke apper som i det hele tatt får bruke tunnelen. En profil kan pare en bred utløser med en smal rute, eller en smal utløser med en standardrute. Les bare den ene halvdelen, og den andre ser ut som en funksjonsfeil.

Jeg har en laboratorieprofil som kobler til når som helst noe under et internt domene blir forespurt, men bare ruter én /16 inn i tunnelen. Den gjør nøyaktig det payloaden sier, og den er også den typen profil som genererer saker: folk antar at en tilkoblet tunnel betyr at trafikken deres er inne i den.

Hva en domeneregel faktisk spør resolveren om

Domenformen av regelen, ofte kalt connect-if-needed, inspiserer ikke pakkepayloader og overvåker ikke URL-er. Når et navn løses opp, sammenligner systemet det med domenene i regelen og spør ved et treff om navnet kan løses opp gjennom DNS-serverne tunnelen tilbyr. Hvis tunnelens resolver svarer, regnes navnet som internt og tilkoblingen startes. Hvis den lokale resolveren svarer i stedet, behandles navnet som eksternt og ingen tunnel dukker opp. Apples oversikt over utrulling beskriver dette som nettverksdeteksjon etterfulgt av tilkoblingsvurdering.

To konsekvenser følger. Profilen må navngi DNS-servere inne i tunnelen; en domeneregel uten tunnelresolver har ingenting å sammenligne med, så vurderingen kan ikke gi treffet du forventer. Og oppslaget må nå systemets resolver. En app eller nettleser som kjører sin egen krypterte DNS, en utvidelse som svarer lokalt, eller en tilkobling til en bokstavelig adresse gir aldri navneoppløsningen regelen ventet på. En av de lengste ettermiddagene jeg har tilbrakt, endte da jeg oppdaget at klienten foran tunnelen brukte DNS over HTTPS.

Bufring fjerner også utløseren. Et navn som allerede ligger i hurtigbufferen kan besvares uten sonden som ville ha startet tunnelen, så en regel som virket i går, feiler etter en omstart eller etter at tunnelen har vært oppe en stund. På macOS nullstiller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder tilstanden; på iOS gir det å slå flymodus av og på eller starte enheten på nytt en sammenlignbar ren tavle.

Treffomfang: navn, apper og nettverk

Domenematching er én type blant flere. En regel kan også matche grensesnitttypen (Wi-Fi, mobil, Ethernet) og en bestemt SSID, og oppføringer per app eller Safari-domene binder en tunnel til én arbeidsflyt. Den bindingen forklarer den merkelige opplevelsen der bare én app oppfører seg annerledes enn alt annet: de andre appene er utenfor tunnelens omfang, så de fortsetter å bruke den lokale veien selv når tunnelikonet sier tilkoblet.

Rekkefølgen betyr mer enn folk forventer. Regler vurderes i rekkefølge og den første som matcher gir handlingen, så en bred koble-til-på-hvilket-som-helst-Wi-Fi-regel over en smal domeneregel vinner stille og gjør domeneregelen utestbar. Før du skriver om domenelisten, bekreft at ingen tidligere regel allerede har matchet.

Derfor er always-on ikke bare en strengere on-demand-regel. Håndheving av always-on er en egen utrullingsmodus med egne krav til overvåking og administrasjon; den holder en tunnel åpen i stedet for å reagere på et navn. Hvis det du trenger er en tunnel som aldri faller, er en domeneregel feil verktøy.

Feilmoduser som imiterer en ødelagt regel

De fleste rapportene om at en domeneregel ikke virker, havner på ett av fem steder, og bare det siste av dem er regelteksten.

Captive-portaler fortjener sin egen linje, fordi Wi-Fi på hoteller og flyplasser fanger opp nettopp oppslaget regelen er avhengig av. Inntil portalen slipper enheten inn, er tunnelens DNS-server utilgjengelig, sonden feiler, og feilen ser ut som et feilstavet domene. Autentisering er det andre stille tilfellet: regelen kan utløses, tunnelen kan begynne å koble til, og tilkoblingen dør på et utløpt sertifikat eller en forespørsel som dukker opp på en annen skjerm.

IPv6 skaper en variant som er lett å feildiagnostisere. Et navn med begge adressefamilier kan besvares først fra en AAAA-post, mens tunnelens ruteliste bare bærer IPv4. Én nettleser lykkes, en annen feiler, og domenelisten er helt uskyldig.

Test med en ekte forespørsel, i denne rekkefølgen

Les policyen før du gjetter. På macOS skriver sudo profiles show -type configuration ut installerte profiler inkludert VPN-payloaden, scutil --nc list viser tjenestestatus, og scutil --nc show <service> skriver ut on-demand-ordboken systemet bruker. På en administrert iPhone eller iPad kommer samme payload fra administrasjonskonsollen eller en MDM-rapport. Nettverkslogger er tilgjengelige med log stream --predicate 'subsystem == "com.apple.networkextension"' på macOS, og via enhetskonsollen når telefonen er tilkoblet.

Test deretter med et vertsnavn som ikke ble spurt om tidligere i økten. Velg et navn i tunnelens DNS-sone som du vet løses internt, be om det én gang, og se om tunnelen dukker opp. Kjør det samme oppslaget to ganger: det andre forsøket trener hurtigbufferveien, og forskjellen mellom de to forteller deg om utløseren er oppløsningen eller rutingen.

Når tunnelen er oppe, verifiser de to lagene separat. netstat -rn -f inet og netstat -rn -f inet6 viser hvor hvert prefiks peker, scutil --dns viser resolverrekkefølgen og hvilket grensesnitt som eier hver resolver, og nettop -m route viser hvilket grensesnitt som bar bytene. Hvis tunnelen er oppe og resolveren er riktig, men ressursen fortsatt feiler, slutt å redigere regelen; sjekk autorisasjon på serversiden og returruten.

Når regelen tilhører noen andre

Hvis tunnelen dukker opp igjen etter at du koblet den fra, tilhører regelen vanligvis en profil og ikke en app: en konfigurasjon som er sendt ut via MDM, en gjenværende personlig profil, eller en profil installert av en annen klient. sudo profiles show -type configuration pluss et søk etter on-demand-nøklene vil snevre det inn, og fjerningsveien er profilen, ikke bryteren i menylinjen. Sletting av tjenesteposten eller appen etterlater regelen, og neste installasjon arver den igjen.

Én test avgjør eierskapet: koble fra, vent, be om det interne navnet igjen. Hvis tunnelen kommer tilbake, virker utløseren som designet, og det åpne spørsmålet er hvem som administrerer den og om det omfanget er det du vil ha.

Før du melder dette som en feil, gå gjennom de samme fem kontrollene: tunnelresolveradresser til stede i payloaden, et navn som ikke var bufret, ingen tidligere regel som allerede matchet, en AAAA-vei som rutelisten dekker, og appen innenfor tunnelens omfang. Når alle fem holder, gjør regelen jobben sin, og feilen ligger lenger fremme i veien.