Sådan udløser Apples VPN On Demand-domæneregler en tunnel

Tunnelen åbner, når du anmoder om ét internt navn, og forbliver lukket, når den næste app har lige så hårdt brug for det. Det er ikke en fejl i appen; det er formen på en domæneregel. Apples on-demand-konfiguration beskriver betingelser for at oprette en forbindelse, og domæneformen af disse betingelser stiller systemets resolver et spørgsmål, før en enkelt pakke bevæger sig. To spørgsmål blandes konstant sammen: hvornår tunnelen skal komme op, og hvad tunnelen bærer, når den først findes. Det første er en udløser, det andet er en rute- og resolverpolitik, og én profil sætter normalt begge i samme payload, hvorfor en korrekt domæneregel stadig kan efterlade dig på det forkerte netværk.

Udløser og trafikvalg ligger i forskellige lag

En on-demand-regel ligger i on-demand-ordbogen i en VPN-payload: en ordnet liste af regler, hver med en handling og et sæt matchbetingelser. Systemet evaluerer dem, når forbindelsen ændrer sig, eller når noget forsøger at nå netværket, og handlingen afgør, om tunnelen rejses, evalueres, afbrydes eller ignoreres. Alt dette sker i platformens netværkslag, før din app har en socket.

Det, der sker bagefter, er en separat gruppe nøgler: tunnelens IPv4- og IPv6-indstillinger, dens inkluderede og ekskluderede ruter, dens DNS-serveradresser og på iOS og iPadOS den per-app-mapping, der afgør, hvilke apps der overhovedet må bruge tunnelen. En profil kan parre en bred udløser med en smal rute eller en smal udløser med en standardrute. Læs kun den ene halvdel, og den anden halvdel ser ud som en fejlfunktion.

Jeg har en laboratorieprofil, der forbinder, når som helst der anmodes om noget under et internt domæne, men kun ruter et /16 ind i tunnelen. Den gør præcis, hvad dens payload siger, og den er også den slags profil, der genererer tickets: folk antager, at en tilsluttet tunnel betyder, at deres trafik er inde i den.

Hvad en domæneregel egentlig spørger resolveren om

Reglens domæneform, ofte kaldet connect-if-needed, undersøger ikke pakkepayloads eller overvåger URL’er. Når et navn opløses, sammenligner systemet det med domænerne i reglen og spørger ved et match, om navnet kan opløses via de DNS-servere, tunnelen stiller til rådighed. Svarer tunnelens resolver, tæller navnet som internt, og forbindelsen startes. Svarer den lokale resolver i stedet, behandles navnet som eksternt, og der vises ingen tunnel. Apples udrulningsoversigt beskriver det som netværksregistrering efterfulgt af forbindelsesevaluering.

To konsekvenser følger. Profilen skal angive DNS-servere inde i tunnelen; en domæneregel uden tunnelresolver har intet at sammenligne med, så evalueringen kan ikke give det match, du forventer. Og opslaget skal nå systemets resolver. En app eller browser, der kører sin egen krypterede DNS, en udvidelse, der svarer lokalt, eller en forbindelse til en bogstavelig adresse frembringer aldrig den navneopløsning, reglen ventede på. En af de længste eftermiddage, jeg har tilbragt, sluttede, da jeg opdagede, at klienten foran tunnelen brugte DNS over HTTPS.

Caching fjerner også udløseren. Et navn, der allerede er i cachen, kan besvares uden den sondering, der ville have startet tunnelen, så en regel, der virkede i går, fejler efter en genstart eller efter, at tunnelen har været oppe et stykke tid. På macOS nulstiller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder tilstanden; på iOS giver det at slå flytilstand til og fra eller genstarte enheden en tilsvarende ren tavle.

Matchomfang: navne, apps og netværk

Domænematch er én type blandt flere. En regel kan også matche grænsefladetypen (Wi-Fi, mobil, Ethernet) og en bestemt SSID, og poster per app eller Safari-domæne binder en tunnel til én arbejdsgang. Den binding forklarer den mærkelige oplevelse, hvor kun én app opfører sig anderledes end alt andet: de andre apps er uden for tunnelens omfang, så de bliver ved med at bruge den lokale vej, selv når tunnelikonet siger tilsluttet.

Rækkefølgen betyder mere, end folk forventer. Regler evalueres i rækkefølge, og den første, der matcher, leverer handlingen, så en bred forbind-på-ethvert-Wi-Fi-regel over en smal domæneregel vinder lydløst og gør domæneregelen utestbar. Før du omskriver domænelisten, skal du bekræfte, at ingen tidligere regel allerede har matchet.

Det er også derfor, always-on ikke bare er en strengere on-demand-regel. Håndhævelse af always-on er en separat udrulningstilstand med sine egne krav til overvågning og styring; den holder en tunnel åben i stedet for at reagere på et navn. Hvis det, du har brug for, er en tunnel, der aldrig falder, er en domæneregel det forkerte værktøj.

Fejltilstande, der efterligner en brudt regel

De fleste rapporter om, at en domæneregel ikke virker, ender et af fem steder, og kun det sidste af dem er reglens tekst.

Captive portals fortjener deres egen linje, fordi hotel- og lufthavns-Wi-Fi opfanger netop det opslag, reglen afhænger af. Indtil portalen lukker enheden ind, er tunnelens DNS-server utilgængelig, sonderingen fejler, og fejlen ser ud som et forkert stavet domæne. Godkendelse er det andet stille tilfælde: reglen kan udløse, tunnelen kan begynde at forbinde, og forbindelsen dør på et udløbet certifikat eller en prompt, der vises på en anden skærm.

IPv6 skaber en variant, der er let at fejldiagnosticere. Et navn med begge adressefamilier kan besvares først fra en AAAA-post, mens tunnelens ruteliste kun bærer IPv4. Én browser lykkes, en anden fejler, og domænelisten er helt uskyldig.

Test med en rigtig anmodning, i denne rækkefølge

Læs politikken, før du gætter. På macOS udskriver sudo profiles show -type configuration installerede profiler inklusive VPN-payloaden, scutil --nc list viser tjenestestatus, og scutil --nc show <service> udskriver den on-demand-ordbog, systemet bruger. På en administreret iPhone eller iPad kommer den samme payload fra administrationskonsollen eller en MDM-rapport. Netværkslogfiler er tilgængelige med log stream --predicate 'subsystem == "com.apple.networkextension"' på macOS og via enhedskonsollen, når telefonen er tilsluttet.

Test derefter med et værtsnavn, der ikke blev forespurgt tidligere i sessionen. Vælg et navn i tunnelens DNS-zone, som du ved opløses internt, anmod om det én gang, og se, om tunnelen dukker op. Kør det samme opslag to gange: det andet forsøg bruger cachevejen, og forskellen mellem de to fortæller dig, om udløseren er opløsningen eller routing.

Når tunnelen er oppe, skal du verificere de to lag separat. netstat -rn -f inet og netstat -rn -f inet6 viser, hvor hvert præfiks peger, scutil --dns viser resolverrækkefølgen og hvilken grænseflade der ejer hver resolver, og nettop -m route viser, hvilken grænseflade der bar bytes. Hvis tunnelen er oppe, og resolveren er korrekt, men ressourcen stadig fejler, skal du stoppe med at redigere reglen; kontroller server-side-godkendelse og returruten.

Når reglen tilhører en anden

Hvis tunnelen dukker op igen, efter du har afbrudt den, tilhører reglen normalt en profil snarere end en app: en MDM-skubbet konfiguration, en efterladt personlig profil eller en profil installeret af en anden klient. sudo profiles show -type configuration plus en søgning efter on-demand-nøglerne vil indsnævre det, og fjernelsesvejen er profilen, ikke kontakten i menulinjen. Sletning af tjenesteposten eller appen efterlader reglen, og den næste installation arver den igen.

Én test afgør ejerskabet: afbryd, vent, anmod om det interne navn igen. Hvis tunnelen vender tilbage, virker udløseren som designet, og det åbne spørgsmål er, hvem der administrerer den, og om det omfang er det, du ønsker.

Før du melder dette som en fejl, skal du gennemgå de samme fem kontroller: tunnelresolveradresser til stede i payloaden, et navn, der ikke var cachet, ingen tidligere regel, der allerede matchede, en AAAA-vej, som rutelisten dækker, og appen inden for tunnelens omfang. Når alle fem holder, gør reglen sit arbejde, og fejlen ligger længere fremme på vejen.