Kako Apple VPN On Demand domenske regule pokreću tunel

Tunel se otvara kada zatražite jedno interno ime, a ostaje zatvoren kada ga sljedeća aplikacija treba jednako jako. To nije greška u aplikaciji; to je oblik domenske regule. Appleova on-demand konfiguracija opisuje uvjete za uspostavljanje veze, a domenski oblik tih uvjeta pita sistemski resolver pitanje prije nego se pomakne i jedan paket. Dva se pitanja stalno miješaju: kada tunel treba podići i što tunel nosi kada postoji. Prvo je okidač, drugo je politika ruta i resolvera, a jedan profil obično postavlja oboje u istom payloadu, zbog čega vas ispravna domenska regula ipak može ostaviti na pogrešnoj mreži.

Okidač i odabir prometa leže na različitim slojevima

On-demand regula živi u on-demand rječniku VPN payloada: uređeni popis regula, svaka s radnjom i skupom uvjeta podudaranja. Sustav ih procjenjuje kada se povezanost promijeni ili kada nešto pokuša doći do mreže, a radnja odlučuje hoće li se tunel podići, procijeniti, prekinuti ili zanemariti. Sve se to događa u mrežnom sloju platforme, prije nego vaša aplikacija dobije socket.

Ono što slijedi odvojena je skupina ključeva: IPv4 i IPv6 postavke tunela, njegove uključene i isključene rute, adrese DNS poslužitelja i na iOS-u i iPadOS-u mapiranje po aplikacijama koje odlučuje koje se aplikacije uopće smiju koristiti tunelom. Profil može upariti široki okidač s uskom rutom ili uski okidač s zadanom rutom. Pročitajte samo jednu polovicu i druga će izgledati kao kvar.

Imam laboratorijski profil koji se povezuje kad god se zatraži bilo što pod internom domenom, ali u tunel usmjerava samo jednu /16. Radi točno ono što njegov payload kaže, a to je i vrsta profila koja stvara tikete: ljudi pretpostavljaju da povezan tunel znači da je njihov promet unutra.

Što domenska regula zapravo pita resolver

Domenski oblik regule, često nazvan connect-if-needed, ne pregledava payload paketa niti promatra URL-ove. Kada se ime razrješava, sustav ga uspoređuje s domenama u regule i, pri podudaranju, pita može li se to ime razriješiti preko DNS poslužitelja koje tunel pruža. Ako resolver tunela odgovori, ime se smatra internim i veza se pokreće. Ako umjesto toga odgovori lokalni resolver, ime se tretira kao vanjsko i tunel se ne pojavljuje. Appleov pregled implementacije to opisuje kao otkrivanje mreže nakon kojeg slijedi procjena veze.

Dvije posljedice slijede. Profil mora navesti DNS poslužitelje unutar tunela; domenska regula bez resolvera tunela nema što usporediti, pa procjena ne može dati podudaranje koje očekujete. I pretraga mora stići do sistemskog resolvera. Aplikacija ili preglednik koji pokreće vlastiti šifrirani DNS, proširenje koje odgovara lokalno ili veza na doslovnu adresu nikada ne proizvode razrješavanje imena koje je regula čekala. Jedno od najduljih poslijepodneva koje sam proveo završilo je kada sam otkrio da klijent ispred tunela koristi DNS over HTTPS.

Keširanje također uklanja okidač. Ime koje je već u kešu može biti odgovoreno bez sonde koja bi pokrenula tunel, pa regula koja je jučer radila ne uspijeva nakon ponovnog pokretanja ili nakon što je tunel neko vrijeme bio podignut. Na macOS-u sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder resetira stanje; na iOS-u prebacivanje zrakoplovnog načina ili ponovno pokretanje uređaja daje vam usporediv čist početak.

Opseg podudaranja: imena, aplikacije i mreže

Podudaranje domena jedan je tip među nekoliko. Regula može odgovarati i tipu sučelja (Wi-Fi, mobilni, Ethernet) i određenom SSID-u, a unosi po aplikaciji ili Safari domeni vežu tunel za jedan radni tok. Ta veza objašnjava čudno iskustvo u kojem se samo jedna aplikacija ponaša drugačije od svega ostalog: druge su aplikacije izvan opsega tunela, pa nastavljaju koristiti lokalnu putanju čak i dok ikona tunela pokazuje povezanost.

Redoslijed je važniji nego što ljudi očekuju. Regule se procjenjuju redom i prva koja se podudari daje radnju, pa široka regula spoji-se-na-bilo-koji-Wi-Fi postavljena iznad uske domenske regule tiho pobjeđuje i čini domensku regulu netestabilnom. Prije nego prepišete popis domena, potvrdite da se nijedna ranija regula već nije podudarila.

Zato always-on nije samo stroža on-demand regula. Provedba always-on odvojen je način implementacije sa svojim zahtjevima za nadzor i upravljanje; drži tunel otvorenim umjesto da reagira na ime. Ako vam treba tunel koji nikada ne pada, domenska regula pogrešan je alat.

Načini kvara koji oponašaju pokvarenu regulu

Većina izvještaja da domenska regula ne radi pada na jedno od pet mjesta, a samo je posljednje od njih tekst regule.

Captive portali zaslužuju svoj redak, jer Wi-Fi u hotelima i zračnim lukama presreće upravo onu pretragu o kojoj regula ovisi. Dok portal ne pusti uređaj, DNS poslužitelj tunela nedostupan je, sonda ne uspijeva, a kvar izgleda kao pogrešno napisana domena. Autentifikacija je drugi tihi slučaj: regula se može aktivirati, tunel može početi se povezivati, a veza umire na isteklom certifikatu ili na upitu koji se pojavi na drugom zaslonu.

IPv6 stvara varijantu koju je lako pogrešno dijagnosticirati. Na ime s obje obitelji adresa može se prvo odgovoriti iz AAAA zapisa, dok popis ruta tunela nosi samo IPv4. Jedan preglednik uspijeva, drugi ne, a popis domena posve je nevin.

Testirajte stvarnim zahtjevom, ovim redom

Pročitajte politiku prije nego što nagađate. Na macOS-u sudo profiles show -type configuration ispisuje instalirane profile uključujući VPN payload, scutil --nc list prikazuje stanje usluge, a scutil --nc show <service> ispisuje on-demand rječnik koji sustav koristi. Na nadziranom iPhoneu ili iPadu isti payload dolazi iz upravljačke konzole ili MDM izvještaja. Mrežni dnevnici dostupni su uz log stream --predicate 'subsystem == "com.apple.networkextension"' na macOS-u i preko konzole uređaja kada je telefon priključen.

Zatim testirajte s imenom hosta koje nije bilo upitano ranije u sesiji. Odaberite ime u DNS zoni tunela za koje znate da se razrješava interno, zatražite ga jednom i gledajte pojavljuje li se tunel. Pokrenite istu pretragu dvaput: drugi pokušaj vježba putanju keša, a razlika između njih govori vam je li okidač razrješavanje ili usmjeravanje.

Nakon što se tunel podigne, provjerite dva sloja odvojeno. netstat -rn -f inet i netstat -rn -f inet6 pokazuju kamo vodi svaki prefiks, scutil --dns pokazuje redoslijed resolvera i koji sučelje posjeduje koji resolver, a nettop -m route pokazuje koje je sučelje prenijelo bajtove. Ako je tunel podignut i resolver ispravan, ali resurs i dalje ne uspijeva, prestanite uređivati regulu; provjerite autorizaciju na strani poslužitelja i povratnu rutu.

Kada regula pripada nekome drugom

Ako se tunel ponovno pojavi nakon što ga isključite, regula obično pripada profilu, a ne aplikaciji: konfiguracija gurnuta putem MDM-a, zaostali osobni profil ili profil koji je instalirao drugi klijent. sudo profiles show -type configuration plus pretraga on-demand ključeva to će suziti, a put uklanjanja je profil, a ne prekidač u traci izbornika. Brisanje unosa usluge ili aplikacije ostavlja regulu iza sebe, a sljedeća instalacija je ponovno nasljeđuje.

Jedan test rješava pitanje vlasništva: isključite, pričekajte, ponovno zatražite interno ime. Ako se tunel vrati, okidač radi kako je dizajniran, a otvoreno je pitanje tko njime upravlja i je li taj opseg ono što želite.

Prije nego ovo prijavite kao grešku, prođite kroz istih pet provjera: adrese resolvera tunela prisutne u payloadu, ime koje nije bilo keširano, nijedna ranija regula koja se već podudarila, AAAA putanja koju popis ruta pokriva i aplikacija unutar opsega tunela. Kada svih pet vrijedi, regula radi svoj posao, a kvar je dalje duž putanje.