Hoe Apple VPN On Demand se domeinreëls ’n tonnel aktiveer

Die tonnel gaan oop wanneer jy een interne naam aanvra en bly toe wanneer die volgende program dit net so nodig het. Dit is nie ’n fout in die program nie; dit is die vorm van ’n domeinreël. Apple se on-demand-konfigurasie beskryf voorwaardes om ’n verbinding te maak, en die domeinvorm van daardie voorwaardes vra die stelselresolver ’n vraag voordat ’n enkele pakkie beweeg. Twee vrae word gedurig verwar: wanneer die tonnel moet opkom, en wat die tonnel dra sodra dit bestaan. Die eerste is ’n sneller, die tweede is ’n roete- en resolverbeleid, en een profiel stel gewoonlik albei in dieselfde loon vas, daarom kan ’n korrekte domeinreël jou steeds op die verkeerde netwerk laat.

Sneller en verkeerskeuse lê op verskillende vlakke

’n On-demand-reël woon in die on-demand-woordeboek van ’n VPN-loon: ’n geordende lys reëls, elk met ’n aksie en ’n stel pasvoorwaardes. Die stelsel evalueer hulle wanneer konnektiwiteit verander of wanneer iets die netwerk probeer bereik, en die aksie besluit of die tonnel opgebring, geëvalueer, ontkoppel of geïgnoreer word. Dit alles gebeur in die platform se netwerklaag, voordat jou program ’n sokket het.

Wat daarna gebeur, is ’n aparte groep sleutels: die tonnel se IPv4- en IPv6-instellings, sy ingeslote en uitgeslote roetes, sy DNS-bedieneradresse, en op iOS en iPadOS die per-program-kartering wat besluit watter programme die tonnel hoegenaamd mag gebruik. ’n Profiel kan ’n breë sneller met ’n smal roete kombineer, of ’n smal sneller met ’n verstekroete. Lees net een helfte en die ander helfte lyk soos ’n fout.

Ek hou ’n laboratoriumprofiel wat verbind wanneer enigiets onder ’n interne domein aangevra word, maar slegs een /16 in die tonnel stuur. Dit doen presies wat sy loon sê, en dit is ook die soort profiel wat kaartjies oplewer: mense aanvaar ’n gekoppelde tonnel beteken hul verkeer is daarbinne.

Wat ’n domeinreël werklik aan die resolver vra

Die domeinvorm van die reël, dikwels connect-if-needed genoem, ondersoek nie pakkieloon of dophou URL’s nie. Wanneer ’n naam opgelos word, vergelyk die stelsel dit met die domeine in die reël en, by ’n passing, vra of daardie naam deur die DNS-bedieners wat die tonnel verskaf, opgelos kan word. As die tonnel se resolver antwoord, geld die naam as intern en die verbinding word begin. As die plaaslike resolver eerder antwoord, word die naam as ekstern beskou en geen tonnel verskyn nie. Apple se ontplooiingsoorsig beskryf dit as netwerkopsporing gevolg deur verbindingsevaluering.

Twee gevolge volg. Die profiel moet DNS-bedieners binne die tonnel noem; ’n domeinreël sonder ’n tonnelresolver het niks om te vergelyk nie, so die evaluering kan nie die passing lewer wat jy verwag nie. En die opsoek moet die stelselresolver bereik. ’n Program of blaaier wat sy eie geënkripteerde DNS bestuur, ’n uitbreiding wat plaaslik antwoord, of ’n verbinding na ’n letterlike adres lewer nooit die naamresolusie waarvoor die reël gewag het nie. Een van die langste middae wat ek deurgebring het, het geëindig toe ek ontdek die kliënt voor die tonnel gebruik DNS over HTTPS.

Kasgeheue verwyder ook die sneller. ’n Naam wat reeds in die kas is, kan geantwoord word sonder die probe wat die tonnel sou begin het, so ’n reël wat gister gewerk het, faal ná ’n herbegin of nadat die tonnel ’n ruk op was. Op macOS stel sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder die toestand terug; op iOS gee die aan- en afskakel van vliegtuigmodus of die herbegin van die toestel jou ’n vergelykbare skoon bladsy.

Pasomvang: name, programme en netwerke

Domeinpassing is een tipe onder verskeie. ’n Reël kan ook die koppelvlaktipes (Wi-Fi, sellulêr, Ethernet) en ’n spesifieke SSID pas, en per-program- of Safari-domeininskrywings bind ’n tonnel aan een werkvloei. Daardie binding verduidelik die vreemde ervaring waar net een program anders as alles anders optree: die ander programme val buite die tonnel se omvang, so hulle bly die plaaslike pad gebruik selfs terwyl die tonnelikoon sê dit is gekoppel.

Orde maak meer saak as wat mense verwag. Reëls word in volgorde geëvalueer en die eerste een wat pas, lewer die aksie, so ’n breë verbind-op-enige-Wi-Fi-reël bo ’n smal domeinreël sal stilweg wen en die domeinreël ontoetsbaar maak. Voordat jy die domeinlys herskryf, bevestig dat geen vroeëre reël reeds gepas het nie.

Dit is ook waarom always-on nie net ’n strenger on-demand-reël is nie. Always-on-afdwinging is ’n aparte ontplooiingsmodus met sy eie toesig- en bestuursvereistes; dit hou ’n tonnel oop in plaas daarvan om op ’n naam te reageer. As jy ’n tonnel nodig het wat nooit val nie, is ’n domeinreël die verkeerde instrument.

Foutmodusse wat soos ’n stukkende reël lyk

Die meeste verslae dat ’n domeinreël nie werk nie, val in een van vyf plekke, en net die laaste daarvan is die reëlteks.

Captive portals verdien hul eie reël, want hotel- en lughawe-Wi-Fi onderskep juis die opsoek waarvan die reël afhang. Totdat die portaal die toestel toelaat, is die tonnel se DNS-bediener onbereikbaar, die probe faal, en die fout lyk soos ’n verkeerd gespelde domein. Verifikasie is die ander stil geval: die reël kan afvuur, die tonnel kan begin verbind, en die verbinding sterf op ’n vervalde sertifikaat of ’n opdrag wat op ’n ander skerm verskyn.

IPv6 veroorsaak ’n variant wat maklik verkeerd gediagnoseer word. ’n Naam met albei adresfamilies kan eerste uit ’n AAAA-rekord geantwoord word, terwyl die tonnel se roetelys net IPv4 dra. Een blaaier slaag, ’n ander faal, en die domeinlys is heeltemal onskuldig.

Toets met ’n werklike versoek, in hierdie volgorde

Lees die beleid voordat jy raai. Op macOS druk sudo profiles show -type configuration geïnstalleerde profiele uit, insluitend die VPN-loon, scutil --nc list wys dienstoestand, en scutil --nc show <service> druk die on-demand-woordeboek uit wat die stelsel gebruik. Op ’n bestuurde iPhone of iPad kom dieselfde loon van die bestuurkonsol of ’n MDM-verslag. Netwerklogs is beskikbaar met log stream --predicate 'subsystem == "com.apple.networkextension"' op macOS, en deur die toestelkonsol wanneer die telefoon gekoppel is.

Toets dan met ’n gasheernaam wat nie vroeër in die sessie navraag gedoen is nie. Kies ’n naam in die tonnel se DNS-sone waarvan jy weet dit los intern op, vra dit een keer aan, en kyk of die tonnel verskyn. Voer dieselfde opsoek twee keer uit: die tweede poging oefen die kaspad, en die verskil tussen die twee sê of die sneller die resolusie of die roetering is.

Nadat die tonnel op is, verifieer die twee lae afsonderlik. netstat -rn -f inet en netstat -rn -f inet6 wys waar elke voorvoegsel wys, scutil --dns wys resolverorde en watter koppelvlak elke resolver besit, en nettop -m route wys watter koppelvlak die grepe gedra het. As die tonnel op is en die resolver korrek is maar die hulpbron steeds faal, stop die redigering van die reël; kyk na bedienerkant-magtiging en die terugroete.

Wanneer die reël aan iemand anders behoort

As die tonnel weer verskyn nadat jy dit ontkoppel het, behoort die reël gewoonlik aan ’n profiel eerder as ’n program: ’n MDM-gestuurde konfigurasie, ’n oorblywende persoonlike profiel, of ’n profiel wat deur ’n ander kliënt geïnstalleer is. sudo profiles show -type configuration plus ’n soektog na die on-demand-sleutels sal dit vernou, en die verwyderingspad is die profiel, nie die skakelaar in die menubalk nie. Die uitvee van die diensinskrywing of die program laat die reël agter, en die volgende installasie erf dit weer.

Een toets beslis eienaarskap: ontkoppel, wag, vra die interne naam weer aan. As die tonnel terugkom, werk die sneller soos ontwerp en die ope vraag is wie dit bestuur en of daardie omvang is wat jy wil hê.

Voordat jy dit as ’n fout rapporteer, werk deur dieselfde vyf kontroles: tonnelresolveradresse teenwoordig in die loon, ’n naam wat nie gekas is nie, geen vroeëre reël wat reeds gepas het nie, ’n AAAA-pad wat die roetelys dek, en die program binne die tonnel se omvang. Wanneer al vyf geld, doen die reël sy werk en die fout lê verder langs die pad.