Kaip Apple VPN On Demand domeno taisyklės paleidžia tunelį
Domeno taisyklė nusprendžia tik, kada atsidaro tunelis. Kaip veikia connect-if-needed DNS patikra, kodėl maršrutai vis dar renkasi srautą ir kaip išbandyti profilį.
Tunelis atsidaro, kai paprašote vieno vidinio vardo, ir lieka uždarytas, kai kitai programai jo reikia lygiai taip pat. Tai ne programos klaida; tai domeno taisyklės forma. Apple on-demand konfigūracija aprašo sąlygas ryšiui užmegzti, o domeninė tų sąlygų forma užduoda sistemos resolveriui klausimą dar prieš pajudant vienam paketui. Nuolat painiojami du klausimai: kada tunelis turi iškilti ir ką tunelis neša, kai jau egzistuoja. Pirmasis yra trigeris, antrasis – maršrutų ir resolverio politika, ir vienas profilis paprastai nustato abu tame pačiame payload, todėl teisinga domeno taisyklė vis tiek gali palikti jus netinkamame tinkle.
Trigeris ir srauto pasirinkimas yra skirtinguose sluoksniuose
On-demand taisyklė gyvena VPN payload on-demand žodyne: tvarkingas taisyklių sąrašas, kiekviena su veiksmu ir atitikimo sąlygų rinkiniu. Sistema jas vertina, kai pasikeičia ryšys arba kai kažkas bando pasiekti tinklą, o veiksmas nusprendžia, ar tunelis pakeliamas, įvertinamas, atjungiamas ar ignoruojamas. Visa tai vyksta platformos tinklo sluoksnyje, prieš jūsų programai gaunant socket.
Tai, kas eina po to, yra atskira raktų grupė: tunelio IPv4 ir IPv6 nustatymai, įtraukti ir neįtraukti maršrutai, DNS serverių adresai ir iOS bei iPadOS atveju priskyrimas pagal programą, kuris nusprendžia, kurios programos apskritai gali naudoti tunelį. Profilis gali suporuoti platų trigerį su siauru maršrutu arba siaurą trigerį su numatytuoju maršrutu. Skaitykite tik vieną pusę, o kita atrodys kaip gedimas.
Turiu laboratorinį profilį, kuris prisijungia, kai tik paprašoma ko nors po vidiniu domenu, bet į tunelį nukreipia tik vieną /16. Jis daro būtent tai, kas parašyta jo payload, ir tai taip pat yra profilio tipas, kuris generuoja bilietus: žmonės mano, kad prisijungęs tunelis reiškia, jog jų srautas yra jo viduje.
Ką domeno taisyklė iš tikrųjų klausia resolverio
Domeninė taisyklės forma, dažnai vadinama connect-if-needed, netikrina paketų payload ir nestebi URL. Kai vardas išsprendžiamas, sistema palygina jį su taisyklėje esančiais domenais ir, jei atitinka, klausia, ar tą vardą galima išspręsti per tunelio teikiamus DNS serverius. Jei tunelio resolveris atsako, vardas laikomas vidiniu ir ryšys pradedamas. Jei vietoj to atsako vietinis resolveris, vardas traktuojamas kaip išorinis ir tunelis nepasirodo. Apple diegimo apžvalga tai apibūdina kaip tinklo aptikimą ir po jo einantį ryšio įvertinimą.
Iš to kyla dvi pasekmės. Profilis turi nurodyti DNS serverius tunelio viduje; domeno taisyklė be tunelio resolverio neturi ko palyginti, todėl vertinimas negali duoti laukiamo atitikimo. Ir užklausa turi pasiekti sistemos resolverį. Programa ar naršyklė, kuri paleidžia savo šifruotą DNS, plėtinys, kuris atsako vietoje, arba ryšys su pažodiniu adresu niekada nesukuria to vardo sprendimo, kurio laukė taisyklė. Vienas ilgiausių mano praleistų popiečių baigėsi, kai atradau, kad klientas prieš tunelį naudojo DNS over HTTPS.
Talpykla taip pat pašalina trigerį. Į jau talpykloje esantį vardą galima atsakyti be patikros, kuri būtų paleidusi tunelį, todėl vakar veikusi taisyklė nepavyksta po perkrovimo arba po to, kai tunelis kurį laiką buvo iškeltas. macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder atstato būseną; iOS lėktuvo režimo įjungimas ir išjungimas arba įrenginio perkrovimas suteikia panašią švarią pradžią.
Atitikimo apimtis: vardai, programos ir tinklai
Domeno atitikimas yra vienas tipas tarp kelių. Taisyklė taip pat gali atitikti sąsajos tipą (Wi-Fi, mobilusis, Ethernet) ir konkretų SSID, o įrašai pagal programą ar Safari domeną susieja tunelį su vienu darbo srautu. Šis ryšys paaiškina keistą patirtį, kai tik viena programa elgiasi kitaip nei visos kitos: kitos programos yra už tunelio apimties, todėl jos toliau naudoja vietinį kelią net tada, kai tunelio piktograma rodo prisijungimą.
Tvarka svarbesnė, nei žmonės tikisi. Taisyklės vertinamos iš eilės ir pirmoji atitikusi suteikia veiksmą, todėl plati taisyklė prisijungti-prie-bet-kurio-Wi-Fi, padėta virš siauros domeno taisyklės, tyliai laimės ir padarys domeno taisyklę netestuojamą. Prieš perrašydami domenų sąrašą patvirtinkite, kad jokia ankstesnė taisyklė jau neatitiko.
Štai kodėl always-on nėra tik griežtesnė on-demand taisyklė. Always-on vykdymas yra atskiras diegimo režimas su savo priežiūros ir valdymo reikalavimais; jis laiko tunelį atidarytą, o ne reaguoja į vardą. Jei jums reikia tunelio, kuris niekada nenukrenta, domeno taisyklė yra netinkamas įrankis.
Gedimų režimai, imituojantys sulaužytą taisyklę
Dauguma pranešimų, kad domeno taisyklė neveikia, patenka į vieną iš penkių vietų, ir tik paskutinė jų yra taisyklės tekstas.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
Captive portalai nusipelno atskiros eilutės, nes viešbučių ir oro uostų Wi-Fi perima būtent tą užklausą, nuo kurios priklauso taisyklė. Kol portalas neįleidžia įrenginio, tunelio DNS serveris nepasiekiamas, patikra nepavyksta, o gedimas atrodo kaip neteisingai parašytas domenas. Autentifikacija yra kitas tylus atvejis: taisyklė gali suveikti, tunelis gali pradėti jungtis, o ryšys miršta dėl pasibaigusio sertifikato arba raginimo, kuris pasirodo kitame ekrane.
IPv6 sukuria variantą, kurį lengva neteisingai diagnozuoti. Vardui su abiem adresų šeimomis pirmiausia gali būti atsakyta iš AAAA įrašo, o tunelio maršrutų sąraše yra tik IPv4. Viena naršyklė pavyksta, kita nepavyksta, o domenų sąrašas visiškai nekaltas.
Išbandykite tikru užklausimu, tokia tvarka
Perskaitykite politiką prieš spėliodami. macOS sudo profiles show -type configuration išspausdina įdiegtus profilius, įskaitant VPN payload, scutil --nc list rodo paslaugos būseną, o scutil --nc show <service> išspausdina on-demand žodyną, kurį naudoja sistema. Valdomame iPhone ar iPad tas pats payload ateina iš valdymo konsolės arba MDM ataskaitos. Tinklo žurnalai prieinami su log stream --predicate 'subsystem == "com.apple.networkextension"' macOS, o per įrenginio konsolę, kai telefonas prijungtas.
Tada išbandykite su kompiuterio vardu, kurio šioje sesijoje dar neklausėte. Pasirinkite vardą tunelio DNS zonoje, apie kurį žinote, kad jis sprendžiamas viduje, paprašykite jo vieną kartą ir stebėkite, ar pasirodys tunelis. Paleiskite tą pačią užklausą du kartus: antras bandymas išnaudoja talpyklos kelią, o skirtumas tarp jų pasako, ar trigeris yra sprendimas, ar maršrutizavimas.
Kai tunelis iškeltas, patikrinkite du sluoksnius atskirai. netstat -rn -f inet ir netstat -rn -f inet6 rodo, kur nukreiptas kiekvienas prefiksas, scutil --dns rodo resolverių tvarką ir kuri sąsaja valdo kiekvieną resolverį, o nettop -m route rodo, kuri sąsaja pernešė baitus. Jei tunelis iškeltas ir resolveris teisingas, bet išteklius vis tiek nepavyksta, nustokite redaguoti taisyklę; patikrinkite serverio pusės autorizaciją ir grįžimo maršrutą.
Kai taisyklė priklauso kam nors kitam
Jei tunelis vėl pasirodo po to, kai jį atjungėte, taisyklė paprastai priklauso profiliui, o ne programai: per MDM paskirstyta konfigūracija, likęs asmeninis profilis arba kito kliento įdiegtas profilis. sudo profiles show -type configuration ir on-demand raktų paieška tai susiaurins, o šalinimo kelias yra profilis, o ne jungiklis meniu juostoje. Ištrynus paslaugos įrašą ar programą taisyklė lieka, ir kitas diegimas vėl ją paveldi.
Vienas testas nusprendžia nuosavybę: atjunkite, palaukite, dar kartą paprašykite vidinio vardo. Jei tunelis grįžta, trigeris veikia taip, kaip suprojektuotas, o atviras klausimas yra, kas jį valdo ir ar ta apimtis yra tai, ko norite.
Prieš pranešdami apie tai kaip klaidą, pereikite tuos pačius penkis patikrinimus: tunelio resolverio adresai yra payload, vardas nebuvo talpykloje, jokia ankstesnė taisyklė jau neatitiko, maršrutų sąrašas apima AAAA kelią, o programa yra tunelio apimtyje. Kai visi penki galioja, taisyklė atlieka savo darbą, o gedimas yra toliau kelyje.