Si rregullat e domenit të Apple VPN On Demand ndezin një tunel

Tuneli hapet kur kërkoni një emër të brendshëm dhe mbetet i mbyllur kur aplikacioni tjetër ka po aq nevojë për të. Ky nuk është një bug në aplikacion; është forma e një rregulli domeni. Konfigurimi on-demand i Apple përshkruan kushtet për të krijuar një lidhje, dhe forma e domenit e këtyre kushteve i bën një pyetje zgjidhësit të sistemit përpara se të lëvizë edhe një paketë e vetme. Dy pyetje ngatërrohen vazhdimisht: kur duhet të ngrihet tuneli dhe çfarë mbart tuneli pasi ekziston. E para është një trigger, e dyta është një politikë rrugësh dhe zgjidhësi, dhe një profil zakonisht vendos të dyja në të njëjtin payload, prandaj një rregull i saktë domeni mund t’ju lërë gjithsesi në rrjetin e gabuar.

Trigger-i dhe zgjedhja e trafikut qëndrojnë në shtresa të ndryshme

Një rregull on-demand jeton në fjalorin on-demand të një payload VPN: një listë e renditur rregullash, secili me një veprim dhe një grup kushtesh përputhjeje. Sistemi i vlerëson ato kur ndryshon lidhja ose kur diçka përpiqet të arrijë rrjetin, dhe veprimi vendos nëse tuneli ngrihet, vlerësohet, shkëputet ose injorohet. E gjithë kjo ndodh në shtresën e rrjetit të platformës, përpara se aplikacioni juaj të ketë një socket.

Ajo që vjen më pas është një grup i veçantë çelësash: cilësimet IPv4 dhe IPv6 të tunelit, rrugët e përfshira dhe të përjashtuara, adresat e serverëve DNS dhe, në iOS dhe iPadOS, hartëzimi për aplikacion që vendos se cilat aplikacione mund të përdorin tunelin. Një profil mund të çiftëzojë një trigger të gjerë me një rrugë të ngushtë, ose një trigger të ngushtë me një rrugë të parazgjedhur. Lexoni vetëm gjysmën dhe gjysma tjetër do të duket si defekt.

Kam një profil laboratori që lidhet sa herë kërkohet diçka nën një domen të brendshëm, por drejton vetëm një /16 në tunel. Bën saktësisht atë që thotë payload-i i tij, dhe është gjithashtu lloji i profilit që gjeneron bileta: njerëzit supozojnë se një tunel i lidhur do të thotë që trafiku i tyre është brenda tij.

Çfarë pyet vërtet një rregull domeni zgjidhësin

Forma e domenit e rregullit, shpesh e quajtur connect-if-needed, nuk inspekton payload-et e paketave dhe nuk vëzhgon URL-të. Kur zgjidhet një emër, sistemi e krahason atë me domenet në rregull dhe, në rast përputhjeje, pyet nëse ai emër mund të zgjidhet përmes serverëve DNS që ofron tuneli. Nëse përgjigjet zgjidhësi i tunelit, emri llogaritet i brendshëm dhe lidhja fillon. Nëse përgjigjet zgjidhësi lokal, emri trajtohet si i jashtëm dhe nuk shfaqet asnjë tunel. Përmbledhja e implementimit të Apple e përshkruan këtë si zbulim i rrjetit i ndjekur nga vlerësimi i lidhjes.

Nga kjo rrjedhin dy pasoja. Profili duhet të emërojë serverë DNS brenda tunelit; një rregull domeni pa zgjidhës tuneli nuk ka çfarë të krahasojë, kështu që vlerësimi nuk mund të japë përputhjen e pritur. Dhe kërkimi duhet të arrijë zgjidhësin e sistemit. Një aplikacion ose shfletues që ekzekuton DNS-në e vet të kriptuar, një shtesë që përgjigjet lokalisht ose një lidhje me një adresë literale nuk prodhojnë kurrë zgjidhjen e emrit që priste rregulli. Një nga pasditet më të gjata që kam kaluar përfundoi kur zbulova se klienti përpara tunelit përdorte DNS over HTTPS.

Edhe cache-i heq trigger-in. Një emër që është tashmë në cache mund të përgjigjet pa sondën që do të kishte nisur tunelin, kështu që një rregull që funksiononte dje dështon pas një rindezjeje, ose pasi tuneli ka qenë lart për një kohë. Në macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder rivendos gjendjen; në iOS ndezja dhe fikja e modalitetit të fluturimit ose rindezja e pajisjes ju jep një fillim të pastër të krahasueshëm.

Shtrirja e përputhjes: emra, aplikacione dhe rrjete

Përputhja e domenit është një lloj mes disa. Një rregull mund të përputhet edhe me llojin e ndërfaqes (Wi-Fi, celular, Ethernet) dhe një SSID të caktuar, dhe hyrjet për aplikacion ose domen Safari lidhin një tunel me një rrjedhë pune. Kjo lidhje shpjegon përvojën e çuditshme ku vetëm një aplikacion sillet ndryshe nga gjithçka tjetër: aplikacionet e tjera janë jashtë shtrirjes së tunelit, kështu që vazhdojnë të përdorin rrugën lokale edhe kur ikona e tunelit thotë i lidhur.

Rendi ka më shumë rëndësi sesa presin njerëzit. Rregullat vlerësohen me radhë dhe i pari që përputhet jep veprimin, kështu që një rregull i gjerë lidhu-në-çdo-Wi-Fi i vendosur mbi një rregull të ngushtë domeni fiton në heshtje dhe e bën rregullin e domenit të patestueshëm. Përpara se të rishkruani listën e domeneve, konfirmoni se asnjë rregull i mëparshëm nuk është përputhur tashmë.

Kjo është arsyeja pse always-on nuk është thjesht një rregull on-demand më i rreptë. Zbatimi i always-on është një mënyrë e veçantë implementimi me kërkesat e veta të mbikëqyrjes dhe menaxhimit; mban një tunel të hapur në vend që të reagojë ndaj një emri. Nëse ju nevojitet një tunel që nuk bie kurrë, një rregull domeni është mjeti i gabuar.

Mënyra dështimi që imitojnë një rregull të thyer

Shumica e raporteve se një rregull domeni nuk funksionon bien në një nga pesë vendet, dhe vetëm i fundit prej tyre është teksti i rregullit.

Portat captive meritojnë rreshtin e tyre, sepse Wi-Fi i hoteleve dhe aeroporteve intercepton pikërisht kërkimin nga i cili varet rregulli. Derisa porta ta lejojë pajisjen, serveri DNS i tunelit është i paarritshëm, sonda dështon dhe dështimi duket si një domen i shkruar gabim. Autentikimi është rasti tjetër i heshtur: rregulli mund të aktivizohet, tuneli mund të fillojë të lidhet dhe lidhja vdes në një certifikatë të skaduar ose në një kërkesë që shfaqet në një ekran tjetër.

IPv6 krijon një variant që diagnostikohet lehtë gabimisht. Një emër me të dy familjet e adresave mund të përgjigjet fillimisht nga një regjistrim AAAA, ndërsa lista e rrugëve të tunelit mban vetëm IPv4. Një shfletues ia del, një tjetër dështon, dhe lista e domeneve është plotësisht e pafajshme.

Testoni me një kërkesë reale, në këtë rend

Lexoni politikën përpara se të hamendësoni. Në macOS sudo profiles show -type configuration printon profilet e instaluara duke përfshirë payload-in VPN, scutil --nc list tregon gjendjen e shërbimit dhe scutil --nc show <service> printon fjalorin on-demand që përdor sistemi. Në një iPhone ose iPad të menaxhuar, i njëjti payload vjen nga konsola e menaxhimit ose një raport MDM. Regjistrat e rrjetit janë të disponueshëm me log stream --predicate 'subsystem == "com.apple.networkextension"' në macOS dhe përmes konsolës së pajisjes kur telefoni është i lidhur.

Pastaj testoni me një emër hosti që nuk është pyetur më parë në këtë sesion. Zgjidhni një emër në zonën DNS të tunelit për të cilin e dini se zgjidhet brenda, kërkoni një herë dhe vëzhgoni nëse shfaqet tuneli. Ekzekutoni të njëjtin kërkim dy herë: përpjekja e dytë ushtron rrugën e cache-it, dhe ndryshimi mes të dyjave ju tregon nëse trigger-i është zgjidhja apo rrugëtimi.

Pasi tuneli të jetë lart, verifikoni dy shtresat veçmas. netstat -rn -f inet dhe netstat -rn -f inet6 tregojnë ku drejtohet çdo prefiks, scutil --dns tregon rendin e zgjidhësve dhe cila ndërfaqe zotëron çdo zgjidhës, dhe nettop -m route tregon cila ndërfaqe mbarti bajtët. Nëse tuneli është lart dhe zgjidhësi është i saktë, por burimi vazhdon të dështojë, ndaloni së redaktuarit rregullin; kontrolloni autorizimin në anën e serverit dhe rrugën e kthimit.

Kur rregulli i përket dikujt tjetër

Nëse tuneli rishfaqet pasi e shkëputni, rregulli zakonisht i përket një profili dhe jo një aplikacioni: një konfigurim i shtyrë përmes MDM, një profil personal i mbetur ose një profil i instaluar nga një klient tjetër. sudo profiles show -type configuration plus një kërkim për çelësat on-demand do ta ngushtojë, dhe rruga e heqjes është profili, jo çelësi në shiritin e menusë. Fshirja e hyrjes së shërbimit ose e aplikacionit e lë rregullin pas, dhe instalimi tjetër e trashëgon përsëri.

Një test i vetëm vendos pronësinë: shkëputni, prisni, kërkoni përsëri emrin e brendshëm. Nëse tuneli kthehet, trigger-i funksionon siç është projektuar dhe pyetja e hapur është kush e menaxhon dhe nëse ajo shtrirje është ajo që dëshironi.

Përpara se ta raportoni këtë si bug, kaloni nëpër të njëjtat pesë kontrolle: adresat e zgjidhësit të tunelit të pranishme në payload, një emër që nuk ishte në cache, asnjë rregull i mëparshëm që ishte përputhur tashmë, një rrugë AAAA e mbuluar nga lista e rrugëve dhe aplikacioni brenda shtrirjes së tunelit. Kur të pesë qëndrojnë, rregulli bën punën e vet dhe defekti është më tej në rrugë.