Nola Apple VPN On Demand domeinu-arauak tunel bat irekitzen duten
Domeinu-arau batek tunela noiz irekiko den soilik erabakitzen du. Nola dabil connect-if-needed DNS zunda, zergatik bideek oraindik trafikoa aukeratzen duten eta nola probatu profila.
Tunela irekitzen da barne-izen bat eskatzen duzunean, eta itxita geratzen da hurrengo aplikazioak behar bezain beste behar duenean. Hori ez da aplikazioko akats bat; domeinu-arau baten forma da. Apple-ren on-demand konfigurazioak konexio bat egiteko baldintzak deskribatzen ditu, eta baldintza horien domeinu-formak sistemaren resolver-ari galdera bat egiten dio pakete bakarra mugitu aurretik. Bi galdera nahasten dira etengabe: noiz altxatu behar den tunela, eta tunelak zer eramaten duen existitzen denean. Lehenengoa abiarazlea da, bigarrena bide eta resolver politika da, eta profil batek biak payload berean ezartzen ditu normalean, horregatik domeinu-arau zuzen batek sare okerrean utz zaitzake.
Abiarazlea eta trafikoaren hautaketa geruza desberdinetan daude
On-demand araua VPN payload baten on-demand hiztegian bizi da: arau zerrenda ordenatua, bakoitza ekintza batekin eta bat-etortze baldintza multzo batekin. Sistemak haiek ebaluatzen ditu konektibitatea aldatzen denean edo zerbait sarera iristen saiatzen denean, eta ekintzak erabakitzen du tunela altxatu, ebaluatu, deskonektatu edo alde batera utzi. Hori guztia plataformaren sare-geruzan gertatzen da, zure aplikazioak socket bat izan baino lehen.
Ondoren datorrena gako multzo bereizi bat da: tunelaren IPv4 eta IPv6 ezarpenak, haren barneko eta kanpoko bideak, DNS zerbitzariaren helbideak eta, iOS eta iPadOS-en, aplikazioko mapaketa, zein aplikaziok erabil dezaketen tunela erabakitzen duena. Profil batek abiarazle zabala bide estu batekin pareka dezake, edo abiarazle estua bide lehenetsi batekin. Irakurri erdi bat soilik eta beste erdia matxura baten antza izango du.
Laborategiko profil bat daukat barne-domeinu baten azpian zerbait eskatzen den bakoitzean konektatzen dena, baina /16 bakarra bideratzen du tunelera. Bere payloadak dioena egiten du zehazki, eta txartelak sortzen dituen profil mota ere bada: jendeak pentsatzen du konektatutako tunelak bere trafikoa barruan dagoela esan nahi duela.
Zer galdetzen dion domeinu-arau batek resolver-ari
Arauaren domeinu-formak, askotan connect-if-needed deituak, ez ditu paketeen payloadak aztertzen ezta URLak behatzen. Izen bat ebazten denean, sistemak arauko domeinuekin alderatzen du eta, bat etorriz gero, galdetzen du izen hori tunelak eskaintzen dituen DNS zerbitzarien bidez ebatzi daitekeen. Tunelaren resolver-ak erantzuten badu, izena barnekotzat hartzen da eta konexioa hasten da. Resolver lokalak erantzuten badu, berriz, izena kanpokotzat hartzen da eta ez da tunelik agertzen. Apple-ren inplementazio-ikuspegiak sare-detekzioa eta ondorengo konexio-ebaluazioa dela deskribatzen du.
Bi ondorio datoz. Profilak tunelaren barruko DNS zerbitzariak izendatu behar ditu; tunel-resolver-ik gabeko domeinu-arauak ez du ezer alderatzeko, beraz ebaluazioak ezin du espero duzun bat-etortzea eman. Eta bilaketak sistemaren resolver-ra iritsi behar du. Bere DNS zifratua exekutatzen duen aplikazio edo nabigatzaile batek, tokian erantzuten duen luzapen batek edo helbide literal baterako konexioak ez du inoiz sortzen arauak itxaroten zuen izen-ebazpena. Igaro dudan arratsalde luzeenetako bat amaitu zen tunelaren aurreko bezeroak DNS over HTTPS erabiltzen zuela aurkitu nuenean.
Cacheak abiarazlea ere kentzen du. Dagoeneko cachean dagoen izen bati tunela abiaraziko zuen zundarik gabe erantzun dakioke, beraz atzo funtzionatu zuen arauak huts egiten du berrabiarazi ondoren edo tunela denbora batez altxatuta egon ondoren. macOS-en sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ek egoera berrezartzen du; iOS-en hegazkin modua piztu eta itzaltzeak edo gailua berrabiarazteak antzeko abiapuntu garbia ematen dizu.
Bat-etortze-esparrua: izenak, aplikazioak eta sareak
Domeinu bat-etortzea hainbat motatako bat da. Arau batek interfaze motarekin (Wi-Fi, mugikorra, Ethernet) eta SSID zehatz batekin ere bat egin dezake, eta aplikazio edo Safari domeinuko sarrerek tunela lan-fluxu bakar batera lotzen dute. Lotura horrek azaltzen du aplikazio bakarra beste guztiengandik desberdin jokatzen duen esperientzia bitxia: beste aplikazioak tunelaren esparrutik kanpo daude, beraz bide lokala erabiltzen jarraitzen dute tunelaren ikonoak konektatuta dioenean ere.
Ordenak jendeak espero baino gehiago axola du. Arauak sekuentzialki ebaluatzen dira eta bat datorren lehenak ematen du ekintza, beraz domeinu-arau estu baten gainean jarritako edozein Wi-Fi-tan-konektatu arau zabalak isilka irabaziko du eta domeinu-araua probagaitz bihurtuko du. Domeinu-zerrenda berridatzi aurretik, egiaztatu aurreko inongo arauk ez duela jada bat egin.
Horregatik always-on ez da on-demand arau zorrotzago bat soilik. Always-on derrigortzea inplementazio modu bereizia da, bere gainbegiratze eta kudeaketa baldintzekin; tunela irekita edukitzen du izen bati erantzun beharrean. Behin ere erortzen ez den tunel bat behar baduzu, domeinu-araua tresna okerra da.
Arau hautsia imitatzen duten hutsegite moduak
Domeinu-arau batek ez duela funtzionatzen duten txostenen gehiengoa bost tokietako batean amaitzen da, eta horietatik azkena soilik da arauaren testua.
| 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 atariek beren lerroa merezi dute, hotel eta aireportuko Wi-Fi-ek arauak dependatzen duen bilaketa bertan atzematen baitute. Atariak gailua onartu arte, tunelaren DNS zerbitzaria iristezina da, zunda huts egiten du eta hutsegitea gaizki idatzitako domeinu baten antza du. Autentifikazioa da beste kasu isila: arauak tiro egin dezake, tunelak konektatzen has daiteke eta konexioa ziurtagiri iraungitu batean edo beste pantaila batean agertzen den eskaera batean hiltzen da.
IPv6-k gaizki diagnostikatzea erraza den aldaera bat sortzen du. Bi helbide-familia dituen izen bati AAAA erregistrotik erantzun dakioke lehenengo, tunelaren bide-zerrendak IPv4 soilik daraman bitartean. Nabigatzaile batek lortzen du, beste batek huts egiten du, eta domeinu-zerrenda erabat errugabea da.
Probatu benetako eskaera batekin, ordena honetan
Irakurri politika asmatu aurretik. macOS-en sudo profiles show -type configuration ek instalatutako profilak inprimatzen ditu, VPN payloada barne, scutil --nc list ek zerbitzuaren egoera erakusten du eta scutil --nc show <service> ek sistemak erabiltzen duen on-demand hiztegia inprimatzen du. Gainbegiratutako iPhone edo iPad batean payload bera kudeaketa-kontsolatik edo MDM txosten batetik iristen da. Sare-erregistroak log stream --predicate 'subsystem == "com.apple.networkextension"' erabiliz daude eskuragarri macOS-en, eta gailuaren kontsolan zehar telefonoa konektatuta dagoenean.
Ondoren probatu saioan lehenago galdetu ez zen ostalari-izen batekin. Aukeratu tunelaren DNS eremuko izen bat barnean ebazten dela dakizuna, eskatu behin, eta begiratu tunela agertzen den. Exekutatu bilaketa bera bi aldiz: bigarren saiakerak cache bidea erabiltzen du, eta bien arteko aldeak abiarazlea ebazpena edo bideratzea den esaten dizu.
Tunela altxatu ondoren, egiaztatu bi geruzak bereizita. netstat -rn -f inet ek eta netstat -rn -f inet6 ek prefijo bakoitza norantz doan erakusten dute, scutil --dns ek resolver-en ordena eta zein interfazek duen resolver bakoitza erakusten du, eta nettop -m route ek zein interfazek eraman dituen byteak erakusten du. Tunela altxatuta eta resolver-a zuzena bada baina baliabideak oraindik huts egiten badu, utzi araua editatzeari; egiaztatu zerbitzariaren aldeko baimena eta itzulera-bidea.
Araua beste norbaitena denean
Deskonektatu ondoren tunela berriro agertzen bada, araua normalean profil batekoa da, ez aplikazio batena: MDM bidez bidalitako konfigurazio bat, soberan geratu zen profil pertsonal bat edo beste bezero batek instalatutako profil bat. sudo profiles show -type configuration eta on-demand gakoen bilaketa batek estutuko dute, eta kentzeko bidea profila da, ez menu-barrako etengailua. Zerbitzu-sarrera edo aplikazioa ezabatzeak araua bertan uzten du, eta hurrengo instalazioak berriro heredatzen du.
Proba bakar batek erabakitzen du jabetza: deskonektatu, itxaron, eskatu barne-izena berriro. Tunela itzultzen bada, abiarazlea diseinatu bezala ari da lanean eta galdera irekia da nork kudeatzen duen eta esparru hori nahi duzuna den.
Hau akats gisa erregistratu aurretik, egin bost egiaztapen berak: tunelaren resolver helbideak payloadan daude, izena ez zegoen cachean, aurreko inongo arauk ez zuen jada bat egin, bide-zerrendak AAAA bidea estaltzen du, eta aplikazioa tunelaren esparruan dago. Bostak betetzen direnean, arauak bere lana egiten du eta hutsegitea bidean harago dago.