Hvernig Apple VPN On Demand lénreglur ræsa göng

Göngin opnast þegar þú biður um eitt innra nafn og haldast lokuð þegar næsta app þarf þess jafn mikið. Þetta er ekki galli í appinu; þetta er form lénreglu. On-demand stilling Apple lýsir skilyrðum fyrir því að koma á tengingu, og lénsform þessara skilyrða spyr resolver kerfisins spurningar áður en eitt pakka hreyfist. Tvær spurningar ruglast stöðugt: hvenær göngin eiga að rísa og hvað göngin flytja þegar þau eru til. Fyrri er kveikja, seinni er stefna fyrir leiðir og resolver, og eitt prófíl stillir yfirleitt bæði í sama payload, þess vegna getur rétt lénregla samt skilið þig eftir á röngu neti.

Kveikja og val umferðar liggja á mismunandi lögum

On-demand regla býr í on-demand orðabók VPN payloads: röðuð listi reglna, hver með aðgerð og sett af samsvörunarskilyrðum. Kerfið metur þær þegar tenging breytist eða þegar eitthvað reynir að ná netinu, og aðgerðin ákveður hvort göngin eru reist, metin, aftengd eða hunsuð. Allt þetta gerist í netlagslagi kerfisins, áður en appið þitt fær socket.

Það sem kemur næst er sérstakur hópur lykla: IPv4 og IPv6 stillingar ganganna, innifaldar og útilokaðar leiðir þeirra, DNS netþjónaheimilisföng og á iOS og iPadOS vörpun per app sem ákveður hvaða öpp mega yfirhöfuð nota göngin. Prófíll getur parað breiða kveikju við þrönga leið, eða þrönga kveikju við sjálfgefna leið. Lestu aðeins annan helminginn og hinn helmingurinn lítur út eins og bilun.

Ég held prófílnum í rannsóknarstofu sem tengist hvenær sem beðið er um eitthvað undir innra léni en beinir aðeins einu /16 inn í göngin. Hann gerir nákvæmlega það sem payload hans segir, og hann er líka sú tegund prófíls sem framleiðir miða: fólk gerir ráð fyrir að tengd göng þýði að umferðin sé inni í þeim.

Hvað lénregla spyr resolverinn í raun

Lénsform reglunnar, oft kölluð connect-if-needed, skoðar ekki payload pakka og fylgist ekki með URL. Þegar nafn er leyst, ber kerfið það saman við lénin í reglunni og spyr við samsvörun hvort hægt sé að leysa nafnið í gegnum DNS netþjónana sem göngin bjóða. Ef resolver ganganna svarar telst nafnið innra og tengingin hefst. Ef resolverinn á staðnum svarar í staðinn er nafnið meðhöndlað sem ytra og engin göng birtast. Yfirlit Apple um uppsetningu lýsir þessu sem netgreiningu og síðan mati á tengingu.

Tvær afleiðingar fylgja. Prófíllinn verður að nefna DNS netþjóna inni í göngunum; lénregla án resolvers ganganna hefur ekkert til að bera saman, svo matið getur ekki gefið samsvörunina sem þú átt von á. Og leitin verður að ná til resolvers kerfisins. App eða vafri sem keyrir eigin dulkóðað DNS, viðbót sem svarar á staðnum eða tenging við bókstaflegt heimilisfang framleiðir aldrei nafnupplausnina sem reglan beið eftir. Einn af lengstu eftirmiðdögum sem ég hef eytt endaði þegar ég uppgötvaði að biðlarinn fyrir framan göngin notaði DNS over HTTPS.

Skyndiminni fjarlægir líka kveikjuna. Nafni sem þegar er í skyndiminni má svara án könnunarinnar sem hefði ræst göngin, svo regla sem virkaði í gær bregst eftir endurræsingu, eða eftir að göngin hafa verið uppi um stund. Á macOS endurstillir sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder stöðuna; á iOS gefur flugstillingarrof eða endurræsing tækisins sambærilega hreina byrjun.

Umfang samsvörunar: nöfn, öpp og net

Lénsamsvörun er ein tegund meðal fleiri. Regla getur líka samsvarað tegund viðmóts (Wi-Fi, farsíma, Ethernet) og tilteknu SSID, og færslur per app eða Safari lén binda göng við eitt vinnuflæði. Þessi binding útskýrir undarlega upplifun þar sem aðeins eitt app hegðar sér öðruvísi en allt annað: hin öppin eru utan umfangs ganganna, svo þau halda áfram að nota staðbundna leiðina jafnvel þegar tákn ganganna segir tengt.

Röðin skiptir meira máli en fólk á von á. Reglur eru metnar í röð og fyrsta samsvörunin gefur aðgerðina, svo breið regla tengja-á-hvaða-Wi-Fi-sem-er sett yfir þrönga lénreglu vinnur hljóðlega og gerir lénregluna óprófanlega. Áður en þú skrifar lénlistann upp á nýtt skaltu staðfesta að engin fyrri regla hafi þegar samsvarað.

Þess vegna er always-on ekki bara strangari on-demand regla. Framfylgni always-on er sérstakur uppsetningarmáti með eigin kröfum um eftirlit og stjórnun; hann heldur göngunum opnum í stað þess að bregðast við nafni. Ef það sem þú þarft er göng sem falla aldrei, þá er lénregla rangt tæki.

Bilunarhamir sem líkja eftir brostinni reglu

Flest tilkynningar um að lénregla virki ekki lenda á einum af fimm stöðum, og aðeins sá síðasti er texti reglunnar.

Captive gáttir eiga sinn eigin texta, því Wi-Fi á hótelum og flugvöllum grípur nákvæmlega þá leit sem reglan byggir á. Þar til gáttin hleypir tækinu inn er DNS netþjónn ganganna óaðgengilegur, könnunin bregst og bilunin lítur út eins og rangt stafað lén. Auðkenning er hitt hljóðláta tilfellið: reglan getur kviknað, göngin geta byrjað að tengjast og tengingin deyr á útrunnu skírteini eða skjá sem birtist á öðrum skjá.

IPv6 skapar afbrigði sem er auðvelt að greina rangt. Nafni með báðum heimilisfangaflokkum má svara fyrst úr AAAA færslu, á meðan leiðalisti ganganna ber aðeins IPv4. Einn vafri tekst, annar bregst, og lénlistinn er algjörlega saklaus.

Prófaðu með raunverulegri beiðni, í þessari röð

Lestu stefnuna áður en þú giskar. Á macOS prentar sudo profiles show -type configuration uppsetta prófíla þar á meðal VPN payload, scutil --nc list sýnir stöðu þjónustunnar og scutil --nc show <service> prentar on-demand orðabókina sem kerfið notar. Á stýrðum iPhone eða iPad kemur sami payload frá stjórnborðinu eða MDM skýrslu. Netlög eru fáanleg með log stream --predicate 'subsystem == "com.apple.networkextension"' á macOS og í gegnum tækjakonsólina þegar síminn er tengdur.

Prófaðu síðan með hýsinafni sem ekki var spurt um fyrr í lotunni. Veldu nafn í DNS svæði ganganna sem þú veist að leysist innra, biddu um það einu sinni og fylgstu með hvort göngin birtast. Keyrðu sömu leit tvisvar: önnur tilraunin æfir skyndiminnisleiðina, og munurinn á þeim segir þér hvort kveikjan er upplausnin eða leiðbeiningin.

Þegar göngin eru uppi skaltu staðfesta lögin tvö hvor í sínu lagi. netstat -rn -f inet og netstat -rn -f inet6 sýna hvert hvert forskeyti stefnir, scutil --dns sýnir röð resolvers og hvaða viðmót á hvern resolver, og nettop -m route sýnir hvaða viðmót bar bætin. Ef göngin eru uppi og resolverinn réttur en auðlindin bregst samt, hættu að breyta reglunni; athugaðu heimild á þjónahlið og púslleiðina.

Þegar reglan tilheyrir einhverjum öðrum

Ef göngin birtast aftur eftir að þú aftengir þau tilheyrir reglan yfirleitt prófíl frekar en appi: stilling sem ýtt var út með MDM, eftirskilin persónuleg prófíll eða prófíll sem annar biðlari setti upp. sudo profiles show -type configuration auk leitar að on-demand lyklunum þrengir það, og fjarlægingarleiðin er prófíllinn, ekki rofinn í valmyndastikunni. Eyðing þjónustufærslunnar eða appsins skilur regluna eftir, og næsta uppsetning erfir hana aftur.

Ein prófun ræður eignarhaldinu: aftengdu, bíddu, biddu aftur um innra nafnið. Ef göngin koma aftur virkar kveikjan eins og hún var hönnuð og opin spurningin er hver stýrir henni og hvort það umfang sé það sem þú vilt.

Áður en þú tilkynnir þetta sem galla skaltu fara í gegnum sömu fimm athuganir: resolverheimilisföng ganganna til staðar í payload, nafn sem var ekki í skyndiminni, engin fyrri regla sem samsvaraði þegar, AAAA leið sem leiðalistinn nær yfir og appið innan umfangs ganganna. Þegar allar fimm standast er reglan að sinna sínu og gallinn er lengra eftir leiðinni.