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 isto tako jako. To nije greška u aplikaciji; to je oblik domenske regule. Apple on-demand konfiguracija opisuje uslove za uspostavljanje veze, a domenski oblik tih uslova pita sistemski resolver pitanje prije nego se pomjeri i jedan paket. Dva pitanja se stalno miješaju: kada tunel treba da se podigne i šta 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 saobraćaja leže na različitim slojevima

On-demand regula živi u on-demand rječniku VPN payloada: uređena lista regula, svaka s akcijom i skupom uslova podudaranja. Sistem ih procjenjuje kada se povezanost promijeni ili kada nešto pokuša doći do mreže, a akcija odlučuje da li se tunel podiže, procjenjuje, prekida ili ignorira. Sve se to dešava u mrežnom sloju platforme, prije nego vaša aplikacija dobije socket.

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

Imam laboratorijski profil koji se povezuje kad god se zatraži bilo šta pod internom domenom, ali u tunel usmjerava samo jednu /16. Radi tač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 saobraćaj unutra.

Šta domenska regula zapravo pita resolver

Domenski oblik regule, često nazvan connect-if-needed, ne pregleda payload paketa niti posmatra URL-ove. Kada se ime razrješava, sistem ga upoređuje s domenama u regule i, pri podudaranju, pita može li se to ime razriješiti preko DNS servera 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 eksterno 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 servere unutar tunela; domenska regula bez resolvera tunela nema šta upoređivati, 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, ekstenzija koja odgovara lokalno ili veza na doslovnu adresu nikada ne proizvode razrješavanje imena koje je regula čekala. Jedno od najdužih poslijepodneva koje sam proveo završilo je kada sam otkrio da klijent ispred tunela koristi DNS over HTTPS.

Keširanje takođe uklanja okidač. Ime koje je već u kešu može biti odgovoreno bez sonde koja bi pokrenula tunel, pa regula koja je juče 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 resetuje stanje; na iOS-u prebacivanje avionskog režima ili ponovno pokretanje uređaja daje vam uporediv čist početak.

Obim podudaranja: imena, aplikacije i mreže

Podudaranje domena je jedan tip među nekoliko. Regula može odgovarati i tipu interfejsa (Wi-Fi, mobilni, Ethernet) i određenom SSID-u, a unosi po aplikaciji ili Safari domeni vezuju 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 aplikacije su izvan obima 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 akciju, pa široka regula poveži-se-na-bilo-koji-Wi-Fi postavljena iznad uske domenske regule tiho pobjeđuje i čini domensku regulu netestabilnom. Prije nego prepišete listu domena, potvrdite da se nijedna ranija regula već nije podudarila.

Zato always-on nije samo stroža on-demand regula. Provodba always-on je odvojen način implementacije sa sopstvenim zahtjevima za nadzor i upravljanje; drži tunel otvorenim umjesto da reaguje na ime. Ako vam treba tunel koji nikada ne pada, domenska regula je pogrešan 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 red, jer Wi-Fi u hotelima i aerodromima presreće upravo onu pretragu o kojoj regula zavisi. Dok portal ne pusti uređaj, DNS server tunela je nedostupan, sonda ne uspijeva, a kvar izgleda kao pogrešno napisana domena. Autentifikacija je drugi tihi slučaj: regula može da se aktivira, tunel može početi da se povezuje, a veza umre na isteklom certifikatu ili na upitu koji se pojavi na drugom ekranu.

IPv6 stvara varijantu koju je lako pogrešno dijagnostikovati. Na ime s obje porodice adresa može se prvo odgovoriti iz AAAA zapisa, dok lista ruta tunela nosi samo IPv4. Jedan preglednik uspijeva, drugi ne, a lista domena je potpuno nevina.

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 sistem koristi. Na nadgledanom iPhoneu ili iPadu isti payload dolazi iz upravljačke konzole ili MDM izvještaja. Mrežni dnevnici dostupni su s 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 da li je okidač razrješavanje ili rutiranje.

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

Kada regula pripada nekome drugom

Ako se tunel ponovo pojavi nakon što ga isključite, regula obično pripada profilu, a ne aplikaciji: konfiguracija gurnuta putem MDM-a, zaostali lični 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 menija. Brisanje unosa usluge ili aplikacije ostavlja regulu iza sebe, a sljedeća instalacija je ponovo nasljeđuje.

Jedan test rješava pitanje vlasništva: isključite, sačekajte, ponovo zatražite interno ime. Ako se tunel vrati, okidač radi kako je dizajniran, a otvoreno pitanje je ko njime upravlja i da li je taj obim 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 lista ruta pokriva i aplikacija unutar obima tunela. Kada svih pet važi, regula radi svoj posao, a kvar je dalje duž putanje.