Kuidas Apple VPN On Demand domeenireeglid tunnelit käivitavad
Domeenireegel otsustab ainult selle, millal tunnel avaneb. Kuidas töötab connect-if-needed DNS-sond, miks marsruudid ikka liiklust valivad ja kuidas profiili testida.
Tunnel avaneb, kui taotlete üht sisemist nime, ja jääb suletuks, kui järgmine rakendus vajab seda sama hädasti. See pole rakenduse viga; see on domeenireegli kuju. Apple’i on-demand-konfiguratsioon kirjeldab ühenduse loomise tingimusi ja nende tingimuste domeenikuju küsib süsteemi resolverilt küsimuse, enne kui liigub ükski pakett. Kaks küsimust aetakse pidevalt segi: millal peaks tunnel tõusma ja mida tunnel pärast olemasolu kannab. Esimene on päästik, teine on marsruudi- ja resolveripoliitika, ning üks profiil seab tavaliselt mõlemad samasse payloadi, mistõttu võib korrektne domeenireegel teid ikkagi valesse võrku jätta.
Päästik ja liikluse valik asuvad eri kihtides
On-demand-reegel elab VPN-payloadi on-demand-sõnastikus: järjestatud reeglite loend, millest igaühel on toiming ja hulk vastavustingimusi. Süsteem hindab neid, kui ühenduvus muutub või kui miski püüab võrku jõuda, ja toiming otsustab, kas tunnel tõstetakse, hinnatakse, katkestatakse või jäetakse tähelepanuta. Kõik see toimub platvormi võrgukihis, enne kui teie rakendus saab socketi.
Järgnev on eraldi võtmete rühm: tunneli IPv4- ja IPv6-seaded, selle kaasatud ja välistatud marsruudid, DNS-serverite aadressid ning iOS-is ja iPadOS-is rakendusepõhine vastendus, mis otsustab, millised rakendused tohivad tunnelit üldse kasutada. Profiil võib siduda laia päästiku kitsa marsruudiga või kitsa päästiku vaikemarsruudiga. Lugege ainult ühte poolt ja teine pool näeb välja nagu rike.
Mul on laboriprofiil, mis ühendub alati, kui sisemise domeeni all midagi taotletakse, kuid suunab tunnelisse ainult ühe /16. See teeb täpselt seda, mida selle payload ütleb, ja see on ka selline profiil, mis tekitab pileteid: inimesed eeldavad, et ühendatud tunnel tähendab, et nende liiklus on selle sees.
Mida domeenireegel resolverilt tegelikult küsib
Reegli domeenikuju, mida sageli nimetatakse connect-if-needed, ei uuri paketi payloadi ega jälgi URL-e. Kui nimi lahendatakse, võrdleb süsteem seda reegli domeenidega ja vastavuse korral küsib, kas seda nime saab lahendada tunneli pakutavate DNS-serverite kaudu. Kui tunneli resolver vastab, loetakse nimi sisemiseks ja ühendus algab. Kui selle asemel vastab kohalik resolver, käsitletakse nime välisena ja tunnelit ei ilmu. Apple’i juurutamise ülevaade kirjeldab seda võrgu tuvastamise ja seejärel ühenduse hindamisena.
Sellest tuleneb kaks tagajärge. Profiil peab nimetama DNS-serverid tunneli sees; tunneliresolverita domeenireeglil pole millegagi võrrelda, seega ei saa hindamine teie oodatud vastavust anda. Ja päring peab jõudma süsteemi resolverini. Rakendus või brauser, mis käitab oma krüpteeritud DNS-i, laiendus, mis vastab kohapeal, või ühendus literaalse aadressiga ei tekita kunagi seda nime lahendamist, mida reegel ootas. Üks pikimaid pärastlõunaid, mille olen veetnud, lõppes, kui avastasin, et tunneli ees olev klient kasutas DNS over HTTPS-i.
Vahemälu eemaldab samuti päästiku. Vahemälus juba olevale nimele võidakse vastata ilma sondita, mis oleks tunneli käivitanud, nii et eile töötanud reegel ebaõnnestub pärast taaskäivitust või pärast seda, kui tunnel on mõnda aega üleval olnud. macOS-is lähtestab sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder oleku; iOS-is annab lennurežiimi sisse-välja lülitamine või seadme taaskäivitamine võrreldava puhta seisu.
Vastavuse ulatus: nimed, rakendused ja võrgud
Domeenivastavus on üks tüüp mitme seas. Reegel võib vastata ka liidese tüübile (Wi-Fi, mobiilne, Ethernet) ja konkreetsele SSID-le, ning rakenduse- või Safari-domeeni kirjed seovad tunneli ühe töövooluga. See side seletab kummalist kogemust, kus ainult üks rakendus käitub kõigist teistest erinevalt: teised rakendused on tunneli ulatusest väljas, nii et nad jätkavad kohaliku tee kasutamist isegi siis, kui tunneli ikoon näitab ühendatust.
Järjekord on tähtsam, kui inimesed ootavad. Reegleid hinnatakse järjest ja esimene vastav annab toimingu, nii et kitsa domeenireegli kohale asetatud lai ühendu-ükskõik-millise-Wi-Fi-ga reegel võidab vaikselt ja muudab domeenireegli testimatuks. Enne domeeniloendi ümberkirjutamist veenduge, et ükski varasem reegel pole juba vastanud.
Seetõttu pole always-on lihtsalt rangem on-demand-reegel. Always-on-i jõustamine on eraldi juurutusrežiim, millel on oma järelevalve- ja haldusnõuded; see hoiab tunneli avatud, selle asemel et nimele reageerida. Kui vajate tunnelit, mis kunagi ei lange, on domeenireegel vale tööriist.
Rikkega sarnanevad tõrked
Enamik teateid, et domeenireegel ei tööta, maanduvad ühte viiest kohast ja ainult viimane neist on reegli tekst.
| 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-portaalid väärivad omaette rida, sest hotelli- ja lennujaama-Wi-Fi püüab kinni täpselt selle päringu, millest reegel sõltub. Kuni portaal seadet ei luba, on tunneli DNS-server kättesaamatu, sond ebaõnnestub ja tõrge näeb välja nagu valesti kirjutatud domeen. Autentimine on teine vaikne juhtum: reegel võib vallanduda, tunnel võib hakata ühenduma ja ühendus sureb aegunud sertifikaadi või teisel ekraanil ilmuva viiba tõttu.
IPv6 loob variandi, mida on lihtne valesti diagnoosida. Mõlema aadressiperekonnaga nimele võidakse esmalt vastata AAAA-kirjest, samal ajal kui tunneli marsruudiloend kannab ainult IPv4-te. Üks brauser õnnestub, teine ebaõnnestub ja domeeniloend on täiesti süütu.
Testige tõelise taotlusega, selles järjekorras
Lugege poliitikat enne oletamist. macOS-is prindib sudo profiles show -type configuration paigaldatud profiilid, sealhulgas VPN-payloadi, scutil --nc list näitab teenuse olekut ja scutil --nc show <service> prindib on-demand-sõnastiku, mida süsteem kasutab. Hallatud iPhone’is või iPadis tuleb sama payload halduskonsoolist või MDM-aruandest. Võrguprotokollid on saadaval käsuga log stream --predicate 'subsystem == "com.apple.networkextension"' macOS-is ja seadme konsooli kaudu, kui telefon on ühendatud.
Seejärel testige hostinimega, mida sesioonis varem ei küsitud. Valige tunneli DNS-tsoonis nimi, mis teie teada lahendatakse sisemiselt, taotlege seda üks kord ja jälgige, kas tunnel ilmub. Käivitage sama päring kaks korda: teine katse kasutab vahemäluteed ja nendevaheline erinevus ütleb teile, kas päästik on lahendamine või marsruutimine.
Kui tunnel on üleval, kontrollige kahte kihti eraldi. netstat -rn -f inet ja netstat -rn -f inet6 näitavad, kuhu iga prefiks osutab, scutil --dns näitab resolverite järjekorda ja seda, milline liides omab iga resolverit, ning nettop -m route näitab, milline liides kandis baidid. Kui tunnel on üleval ja resolver on õige, kuid ressurss ikka ei toimi, lõpetage reegli muutmine; kontrollige serveripoolset autoriseerimist ja tagasimarsruuti.
Kui reegel kuulub kellelegi teisele
Kui tunnel ilmub pärast katkestamist uuesti, kuulub reegel tavaliselt profiilile, mitte rakendusele: MDM-i kaudu saadetud konfiguratsioon, üle jäänud isiklik profiil või teise kliendi paigaldatud profiil. sudo profiles show -type configuration pluss on-demand-võtmete otsing kitsendab selle ja eemaldamise tee on profiil, mitte menüüriba lüliti. Teenusekirje või rakenduse kustutamine jätab reegli alles ja järgmine paigaldus pärib selle uuesti.
Üks test otsustab omandi: katkestage, oodake, taotlege sisemist nime uuesti. Kui tunnel naaseb, töötab päästik nii, nagu projekteeritud, ja lahtine küsimus on, kes seda haldab ja kas see ulatus on see, mida soovite.
Enne kui esitate selle veana, käige läbi samad viis kontrolli: tunneli resolveri aadressid on payloadis olemas, nimi ei olnud vahemälus, ükski varasem reegel pole juba vastanud, marsruudiloend katab AAAA-tee ja rakendus on tunneli ulatuses. Kui kõik viis kehtivad, teeb reegel oma tööd ja viga on marsruudil kaugemal.