Kako Apple VPN On Demand domenska pravila pokreću tunel

Tunel se otvara kada zatražite jedno interno ime, a ostaje zatvoren kada ga sledeća aplikacija treba jednako jako. To nije greška u aplikaciji; to je oblik domenskog pravila. Apple on-demand konfiguracija opisuje uslove za uspostavljanje veze, a domenski oblik tih uslova pita sistemski resolver pitanje pre nego što se pomeri i jedan paket. Dva pitanja se stalno meš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 ispravno domensko pravilo ipak može ostaviti na pogrešnoj mreži.

Okidač i odabir saobraćaja leže na različitim slojevima

On-demand pravilo živi u on-demand rečniku VPN payloada: uređena lista pravila, svako sa akcijom i skupom uslova podudaranja. Sistem ih procenjuje kada se povezanost promeni ili kada nešto pokuša da dođe do mreže, a akcija odlučuje da li se tunel podiže, procenjuje, prekida ili ignoriše. Sve se to dešava u mrežnom sloju platforme, pre nego vaša aplikacija dobije socket.

Ono što sledi 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 smeju da koriste tunel. Profil može da upari široki okidač sa uskom rutom ili uski okidač sa podrazumevanom 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 usmerava 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 domensko pravilo zapravo pita resolver

Domenski oblik pravila, često nazvan connect-if-needed, ne pregleda payload paketa niti posmatra URL-ove. Kada se ime razrešava, sistem ga upoređuje sa domenama u pravilu i, pri podudaranju, pita može li se to ime razrešiti preko DNS servera koje tunel pruža. Ako resolver tunela odgovori, ime se smatra internim i veza se pokreće. Ako umesto 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 sledi procena veze.

Dve posledice slede. Profil mora da navede DNS servere unutar tunela; domensko pravilo bez resolvera tunela nema šta da upoređuje, pa procena ne može da da podudaranje koje očekujete. I pretraga mora da stigne do sistemskog resolvera. Aplikacija ili pregledač koji pokreće sopstveni šifrovani DNS, ekstenzija koja odgovara lokalno ili veza na doslovnu adresu nikada ne proizvode razrešavanje imena koje je pravilo čekalo. Jedno od najdužih poslepodneva koje sam proveo završilo se 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 pravilo koje je juče radilo ne uspeva nakon ponovnog pokretanja ili nakon što je tunel neko vreme 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 jedan je tip među nekoliko. Pravilo može da odgovara 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 da koriste lokalnu putanju čak i dok ikona tunela pokazuje povezanost.

Redosled je važniji nego što ljudi očekuju. Pravila se procenjuju redom i prvo koje se podudari daje akciju, pa široko pravilo poveži-se-na-bilo-koji-Wi-Fi postavljeno iznad uskog domenskog pravila tiho pobeđuje i čini domensko pravilo netestabilnim. Pre nego što prepišete listu domena, potvrdite da se nijedno ranije pravilo već nije podudarilo.

Zato always-on nije samo strože on-demand pravilo. Provodba always-on je odvojen način implementacije sa sopstvenim zahtevima za nadzor i upravljanje; drži tunel otvorenim umesto da reaguje na ime. Ako vam treba tunel koji nikada ne pada, domensko pravilo je pogrešan alat.

Načini kvara koji oponašaju pokvareno pravilo

Većina izveštaja da domensko pravilo ne radi pada na jedno od pet mesta, a samo je poslednje od njih tekst pravila.

Captive portali zaslužuju svoj red, jer Wi-Fi u hotelima i aerodromima presreće upravo onu pretragu o kojoj pravilo zavisi. Dok portal ne pusti uređaj, DNS server tunela je nedostupan, sonda ne uspeva, a kvar izgleda kao pogrešno napisana domena. Autentifikacija je drugi tihi slučaj: pravilo 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 sa obe porodice adresa može se prvo odgovoriti iz AAAA zapisa, dok lista ruta tunela nosi samo IPv4. Jedan pregledač uspeva, drugi ne, a lista domena je potpuno nevina.

Testirajte stvarnim zahtevom, ovim redom

Pročitajte politiku pre 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 rečnik koji sistem koristi. Na nadgledanom iPhoneu ili iPadu isti payload dolazi iz upravljačke konzole ili MDM izveštaja. Mrežni dnevnici dostupni su sa log stream --predicate 'subsystem == "com.apple.networkextension"' na macOS-u i preko konzole uređaja kada je telefon priključen.

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

Nakon što se tunel podigne, proverite dva sloja odvojeno. netstat -rn -f inet i netstat -rn -f inet6 pokazuju kuda vodi svaki prefiks, scutil --dns pokazuje redosled resolvera i koji interfejs poseduje koji resolver, a nettop -m route pokazuje koji je interfejs preneo bajtove. Ako je tunel podignut i resolver ispravan, ali resurs i dalje ne uspeva, prestanite da uređujete pravilo; proverite autorizaciju na strani servera i povratnu rutu.

Kada pravilo pripada nekome drugom

Ako se tunel ponovo pojavi nakon što ga isključite, pravilo 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 pravilo iza sebe, a sledeća instalacija ga ponovo nasleđuje.

Jedan test reš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.

Pre nego što ovo prijavite kao grešku, prođite kroz istih pet provera: adrese resolvera tunela prisutne u payloadu, ime koje nije bilo keširano, nijedno ranije pravilo koje se već podudarilo, AAAA putanja koju lista ruta pokriva i aplikacija unutar obima tunela. Kada svih pet važi, pravilo radi svoj posao, a kvar je dalje duž putanje.