Hoe Apple VPN On Demand-domeinregels in tunnel aktivearje
In domeinregel beslút allinnich wannear’t de tunnel iepen giet. Hoe’t de connect-if-needed-DNS-probe wurket, wêrom’t rûtes noch ferkear kieze en hoe’t jo it profyl testen.
De tunnel iepenet as jo ien ynterne namme oanfreegje en bliuwt ticht as de folgjende app it like hurd nedich hat. Dat is gjin bug yn ’e app; it is de foarm fan in domeinregel. De on-demand-konfiguraasje fan Apple beskriuwt betingsten foar it meitsjen fan in ferbining, en de domeinfarm fan dy betingsten freget de systeemresolver in fraach foardat ien pakket beweecht. Twa fragen wurde hieltyd ferwiksele: wannear’t de tunnel omheech moat, en wat de tunnel draacht as er ienris bestiet. It earste is in trigger, it twadde is in belied foar rûtes en resolver, en ien profyl set meast beide yn deselde payload, wêrtroch’t in krekte domeinregel jo dochs op it ferkearde netwurk litte kin.
Trigger en ferkearsseleksje lizze op ferskate lagen
In on-demand-regel wennet yn it on-demand-woordenboek fan in VPN-payload: in oardere list fan regels, elk mei in aksje en in set fan oerienkomstbetingsten. It systeem evaluearret se as konnektiviteit feroaret of as eat it netwurk besiket te berikken, en de aksje beslút oft de tunnel omheech brocht, evaluearre, ferbûn of negearre wurdt. Dat alles bart yn ’e netwurklaach fan it platfoarm, foardat jo app in socket hat.
Wat dêrnei komt is in aparte groep kaaien: de IPv4- en IPv6-ynstellingen fan ’e tunnel, syn opnommen en útsletten rûtes, syn DNS-tsjinneradressen, en op iOS en iPadOS de mapping per app dy’t beslút hokker apps de tunnel oeral brûke meie. In profyl kin in brede trigger mei in smelle rûte keppelje, of in smelle trigger mei in standertrûte. Lês mar ien helte en de oare helte liket in steuring.
Ik haw in laboratoariumprofyl dat ferbynt as eat ûnder in ynterne domein oanfrege wurdt, mar mar ien /16 yn ’e tunnel rûtet. It docht krekt wat syn payload seit, en it is ek it soarte profyl dat tickets generearet: minsken nimme oan dat in ferbûne tunnel betsjut dat har ferkear der yn sit.
Wat in domeinregel de resolver echt freget
De domeinfarm fan ’e regel, faak connect-if-needed neamd, ûndersiket gjin pakketpayloads en folget gjin URL’s. As in namme oplost wurdt, fergeliket it systeem dy mei de domeinen yn ’e regel en freget by in oerienkomst oft dy namme fia de DNS-tsjinners oplost wurde kin dy’t de tunnel leveret. As de resolver fan ’e tunnel antwurdet, jildt de namme as yntern en wurdt de ferbining start. As de lokale resolver ynstee antwurdet, wurdt de namme as ekstern behannele en ferskynt gjin tunnel. It oersjoch fan Apple oer ymplemintaasje beskriuwt dit as netwurkdeteksje folge troch ferbiningswurdearring.
Twa gefolgen folgje. It profyl moat DNS-tsjinners binnen de tunnel neame; in domeinregel sûnder tunnelresolver hat neat te fergelykjen, dus de evaluaasje kin de oerienkomst dy’t jo ferwachtsje net leverje. En de opfraach moat de systeemresolver berikke. In app of browser dy’t syn eigen fersifere DNS draait, in ekstinsje dy’t lokaal antwurdet, of in ferbining nei in letterlik adres produsearret nea de namme-oplossing dêr’t de regel op wachte. Ien fan ’e langste middeis dy’t ik trochbrocht haw, einige doe’t ik ûntduts dat de klient foar de tunnel DNS over HTTPS brûkte.
Caching hellet de trigger ek fuort. In namme dy’t al yn ’e cache sit kin beantwurde wurde sûnder de probe dy’t de tunnel start hawwe soe, dus in regel dy’t juster wurke, mislearret nei in werstart of neidat de tunnel in skoft omheech stien hat. Op macOS set sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder de steat werom; op iOS jouwe it oan- en útskeakeljen fan fleanmodus of it werstarten fan it apparaat jo in ferlykbere skjinne begjinstiid.
Oerienkomstberik: nammen, apps en netwurken
Domeinoerienkomst is ien type fan ferskate. In regel kin ek oerienkomme mei it ynterfacetype (Wi-Fi, mobyl, Ethernet) en in spesifike SSID, en yngongen per app of Safari-domein bine in tunnel oan ien wurkstream. Dy binding ferklearret de frjemde ûnderfining wêrby’t mar ien app oars docht as al it oare: de oare apps binne bûten it berik fan ’e tunnel, dus se bliuwe it lokale paad brûke sels as it tunnelikoan ferbûn seit.
Oarder is wichtiger as minsken ferwachtsje. Regels wurde op folchoarder evaluearre en de earste dy’t oerienkomt leveret de aksje, dus in brede ferbine-op-alle-Wi-Fi-regel boppe in smelle domeinregel sil stil winnen en de domeinregel net-testber meitsje. Foardat jo de domeinlist oerskriuwe, befêstigje dat gjin eardere regel al oerienkaam.
Dêrom is always-on net samar in strangere on-demand-regel. It hanthavenjen fan always-on is in aparte ymplemintaasjemodus mei eigen easken foar tafersjoch en behear; it hâldt in tunnel iepen ynstee fan op in namme te reagearjen. As jo in tunnel nedich hawwe dy’t nea falt, is in domeinregel it ferkearde helpmiddel.
Steuringen dy’t in brutsen regel neibeare
De measte meldingen dat in domeinregel net wurket, lânje op ien fan fiif plakken, en allinnich it lêste dêrfan is de tekst fan ’e regel.
| 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-portalen fertsjinje har eigen rigel, want Wi-Fi yn hotels en fleanfjilden ûnderskept krekt de opfraach dêr’t de regel fan ôfhinget. Oant it portaal it apparaat talit, is de DNS-tsjinner fan ’e tunnel ûnberikber, mislearret de probe, en liket de steuring op in ferkeard stavere domein. Autentikaasje is it oare stille gefal: de regel kin ôfgean, de tunnel kin begjinne te ferbinen, en de ferbining stjert op in ferfallen sertifikaat of in oanfrege dy’t op in oar skerm ferskynt.
IPv6 makket in fariant dy’t maklik ferkeard diagnostisearre wurdt. In namme mei beide adresfamyljes kin earst út in AAAA-record beantwurde wurde, wylst de rûtelist fan ’e tunnel allinnich IPv4 draacht. Ien browser slagget, in oare mislearret, en de domeinlist is folslein ûnskuldich.
Test mei in echte oanfraach, yn dizze folchoarder
Lês it belied foardat jo riede. Op macOS prints sudo profiles show -type configuration ynstalleare profilen út, ynklusyf de VPN-payload, scutil --nc list toant de tsjinststeat, en scutil --nc show <service> prints it on-demand-woordenboek út dat it systeem brûkt. Op in beheard iPhone of iPad komt deselde payload fan ’e behearkonsole of in MDM-rapport. Netwurkloks binne beskikber mei log stream --predicate 'subsystem == "com.apple.networkextension"' op macOS, en fia de apparaatkonsole as de telefoan oansletten is.
Test dan mei in hostnamme dy’t earder yn ’e sesje net opfrege is. Kies in namme yn ’e DNS-sône fan ’e tunnel dêr’t jo fan witte dat er yntern oplost, freegje dy ien kear oan, en sjoch oft de tunnel ferskynt. Rinn deselde opfraach twa kear: de twadde poging brûkt it cachepaad, en it ferskil tusken beide fertelt jo oft de trigger de oplossing of de rûtering is.
Neidat de tunnel omheech is, ferifiearje de twa lagen apart. netstat -rn -f inet en netstat -rn -f inet6 toane wêr’t elk foarheaksel hinne wiist, scutil --dns toant de resolverfolchoarder en hokker ynterface elke resolver besit, en nettop -m route toant hokker ynterface de bytes droegen hat. As de tunnel omheech is en de resolver kloppet mar it boarne mislearret noch, stopje dan mei it bewurkjen fan ’e regel; kontrolearje server-side autorisaasje en de weromrûte.
As de regel fan immen oars is
As de tunnel wer ferskynt neidat jo him ferbûn hawwe, heart de regel meast ta in profyl ynstee fan in app: in konfiguraasje dy’t troch MDM pusht is, in oerbleaun persoanlik profyl, of in profyl dat troch in oare klient ynstallearre is. sudo profiles show -type configuration plus in syktocht nei de on-demand-kaaien sil it ferfynje, en it fuortheljen giet fia it profyl, net fia de skakel yn ’e menubalke. It wiskjen fan ’e tsjinstyngong of de app lit de regel efter, en de folgjende ynstallaasje erft him wer.
Ien test beslist it eigendom: ferbine, wachtsje, freegje de ynterne namme wer oan. As de tunnel weromkomt, wurket de trigger sa’t er ûntwurpen is en is de iepen fraach wa’t him beheart en oft dat berik is wat jo wolle.
Foardat jo dit as bug oanmelde, rin deselde fiif kontrôles troch: tunnelresolveradressen oanwêzich yn ’e payload, in namme dy’t net cached wie, gjin eardere regel dy’t al oerienkaam, in AAAA-paad dat de rûtelist dekt, en de app binnen it berik fan ’e tunnel. As alle fiif hâlde, docht de regel syn wurk en leit de flater fierder op it paad.