Hogyan indítanak tunelt az Apple VPN On Demand tartományi szabályai

Az alagút akkor nyílik meg, amikor egy belső nevet kérsz, és zárva marad, amikor a következő alkalmazásnak ugyanannyira szüksége van rá. Ez nem hiba az alkalmazásban; ez egy tartományi szabály formája. Az Apple on-demand konfigurációja a kapcsolat létrehozásának feltételeit írja le, és e feltételek tartományi formája még egyetlen csomag mozdulása előtt kérdez a rendszer resolverétől. Két kérdés keveredik állandóan: mikor kell az alagútnak feljönnie, és mit szállít az alagút, miután létezik. Az első egy kiváltó, a második egy útvonal- és resolver-házirend, és egy profil általában mindkettőt ugyanabban a payloadban állítja be, ezért egy helyes tartományi szabály is a rossz hálózaton hagyhat.

A kiváltó és a forgalom kiválasztása különböző rétegekben van

Az on-demand szabály a VPN payload on-demand szótárában él: rendezett szabálylista, mindegyik egy művelettel és egy sor egyezési feltétellel. A rendszer akkor értékeli őket, amikor a kapcsolódás megváltozik, vagy amikor valami el akarja érni a hálózatot, és a művelet dönti el, hogy az alagút feljön-e, kiértékelődik-e, megszakad-e vagy figyelmen kívül marad. Mindez a platform hálózati rétegében történik, mielőtt az alkalmazásod socketet kapna.

Ami ezután következik, az külön kulcscsoport: az alagút IPv4- és IPv6-beállításai, belefoglalt és kizárt útvonalai, DNS-kiszolgáló címei, valamint iOS-en és iPadOS-en az alkalmazásonkénti leképezés, amely eldönti, mely alkalmazások használhatják egyáltalán az alagutat. Egy profil széles kiváltót párosíthat szűk útvonallal, vagy szűk kiváltót alapértelmezett útvonallal. Csak az egyik felét olvasd, és a másik fele meghibásodásnak tűnik.

Van egy laborprofilom, amely akkor kapcsolódik, amikor egy belső tartomány alatt bármit kérnek, de csak egy /16-ot irányít az alagútba. Pontosan azt teszi, amit a payloadja mond, és ez is az a profiltípus, amely jegyeket generál: az emberek azt feltételezik, hogy a csatlakozott alagút azt jelenti, hogy a forgalmuk benne van.

Mit kérdez valójában a tartományi szabály a resolvertől

A szabály tartományi formája, amelyet gyakran connect-if-needed néven említenek, nem vizsgálja a csomagok payloadját és nem figyeli az URL-eket. Amikor egy név feloldódik, a rendszer összehasonlítja a szabályban szereplő tartományokkal, és egyezés esetén megkérdezi, feloldható-e a név az alagút által biztosított DNS-kiszolgálókon keresztül. Ha az alagút resolvere válaszol, a név belsőnek számít, és a kapcsolat elindul. Ha helyette a helyi resolver válaszol, a név külsőnek minősül, és nem jelenik meg alagút. Az Apple telepítési áttekintése ezt hálózatfelismerésként, majd kapcsolatkiértékelésként írja le.

Két következmény adódik. A profilnak DNS-kiszolgálókat kell megneveznie az alagúton belül; az alagút resolvere nélküli tartományi szabálynak nincs mit összehasonlítania, így az értékelés nem tudja előállítani a várt egyezést. És a lekérdezésnek el kell érnie a rendszer resolverét. Egy alkalmazás vagy böngésző, amely saját titkosított DNS-t futtat, egy helyben válaszoló kiterjesztés, vagy egy literális címre irányuló kapcsolat soha nem állítja elő azt a névfeloldást, amelyre a szabály várt. Az egyik leghosszabb délutánom akkor ért véget, amikor rájöttem, hogy az alagút előtti kliens DNS over HTTPS-t használt.

A gyorsítótárazás is megszünteti a kiváltót. Egy már a gyorsítótárban lévő névre a próba nélkül is lehet válaszolni, amely elindította volna az alagutat, ezért a tegnap működő szabály újraindítás után, vagy miután az alagút egy ideig fent volt, meghiúsul. macOS-en a sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder visszaállítja az állapotot; iOS-en a repülőgép mód be- és kikapcsolása vagy az eszköz újraindítása hasonló tiszta lapot ad.

Egyezési hatókör: nevek, alkalmazások és hálózatok

A tartományegyezés egy típus a többiek között. Egy szabály egyezhet az interfész típusával (Wi-Fi, mobil, Ethernet) és egy adott SSID-vel is, az alkalmazásonkénti vagy Safari-tartomány bejegyzések pedig egy munkafolyamathoz kötik az alagutat. Ez a kötés magyarázza azt a furcsa élményt, amikor csak egy alkalmazás viselkedik másképp, mint minden más: a többi alkalmazás az alagút hatókörén kívül van, ezért továbbra is a helyi útvonalat használják, még akkor is, ha az alagút ikonja csatlakozottat mutat.

A sorrend fontosabb, mint az emberek várják. A szabályok sorban értékelődnek, és az első egyező adja a műveletet, ezért egy szűk tartományi szabály fölé helyezett széles kapcsolódj-bármelyik-Wi-Fi-re szabály csendben nyer, és tesztelhetetlenné teszi a tartományi szabályt. Mielőtt átírod a tartománylistát, erősítsd meg, hogy egyetlen korábbi szabály sem egyezett már.

Ezért az always-on nem csupán szigorúbb on-demand szabály. Az always-on kikényszerítése külön telepítési mód, saját felügyeleti és kezelési követelményekkel; nyitva tartja az alagutat ahelyett, hogy egy névre reagálna. Ha olyan alagútra van szükséged, amely soha nem esik el, a tartományi szabály a rossz eszköz.

Törött szabályt utánzó hibaállapotok

A legtöbb jelentés, miszerint egy tartományi szabály nem működik, öt hely valamelyikére esik, és csak az utolsó közülük maga a szabály szövege.

A captive portálok saját sort érdemelnek, mert a szállodai és repülőtéri Wi-Fi éppen azt a lekérdezést fogja el, amelytől a szabály függ. Amíg a portál nem engedi be az eszközt, az alagút DNS-kiszolgálója elérhetetlen, a próba meghiúsul, és a hiba úgy néz ki, mint egy elírt tartomány. A hitelesítés a másik csendes eset: a szabály elsülhet, az alagút elkezdhet csatlakozni, és a kapcsolat meghal egy lejárt tanúsítványon vagy egy másik kijelzőn megjelenő kérésen.

Az IPv6 olyan változatot hoz létre, amelyet könnyű félrediagnosztizálni. Egy mindkét címcsaláddal rendelkező névre először AAAA-rekordból lehet válaszolni, miközben az alagút útvonallistája csak IPv4-et hordoz. Az egyik böngésző sikeres, a másik meghiúsul, és a tartománylista teljesen ártatlan.

Valódi kéréssel teszteld, ebben a sorrendben

Olvasd el a házirendet, mielőtt találgatnál. macOS-en a sudo profiles show -type configuration kiírja a telepített profilokat, köztük a VPN payloadot, a scutil --nc list megmutatja a szolgáltatás állapotát, a scutil --nc show <service> pedig kiírja azt az on-demand szótárat, amelyet a rendszer használ. Egy felügyelt iPhone-on vagy iPaden ugyanez a payload a kezelőkonzolról vagy egy MDM-jelentésből érkezik. Hálózati naplók a log stream --predicate 'subsystem == "com.apple.networkextension"' paranccsal érhetők el macOS-en, és az eszközkonzolon keresztül, amikor a telefon csatlakoztatva van.

Ezután olyan hosztnévvel tesztelj, amelyet korábban nem kérdeztek le a munkamenetben. Válassz egy nevet az alagút DNS-zónájában, amelyről tudod, hogy belsőleg feloldódik, kérd le egyszer, és figyeld, megjelenik-e az alagút. Futtasd ugyanazt a lekérdezést kétszer: a második próbálkozás a gyorsítótár útvonalát gyakorolja, és a kettő közötti különbség megmondja, hogy a kiváltó a feloldás vagy az útválasztás.

Miután az alagút fent van, ellenőrizd a két réteget külön. A netstat -rn -f inet és a netstat -rn -f inet6 megmutatja, hova mutat az egyes prefixek, a scutil --dns a resolverek sorrendjét és azt, hogy melyik interfész melyik resolverhez tartozik, a nettop -m route pedig azt, hogy melyik interfész vitte a bájtokat. Ha az alagút fent van és a resolver helyes, de az erőforrás továbbra is meghiúsul, hagyd abba a szabály szerkesztését; ellenőrizd a kiszolgálóoldali engedélyezést és a visszaútvonalat.

Amikor a szabály valaki másé

Ha az alagút a leválasztás után újra megjelenik, a szabály általában egy profilhoz, nem egy alkalmazáshoz tartozik: MDM-en keresztül kiküldött konfiguráció, maradék személyes profil vagy egy másik kliens által telepített profil. A sudo profiles show -type configuration és az on-demand kulcsokra való keresés szűkíti, és az eltávolítás útja a profil, nem a menüsor kapcsolója. A szolgáltatásbejegyzés vagy az alkalmazás törlése maga után hagyja a szabályt, és a következő telepítés újra örökli.

Egyetlen teszt eldönti a tulajdonjogot: válaszd le, várj, kérd újra a belső nevet. Ha az alagút visszatér, a kiváltó a tervezés szerint működik, és a nyitott kérdés az, ki kezeli, és hogy az a hatókör-e, amit szeretnél.

Mielőtt hibaként jelentenéd, menj végig ugyanazon az öt ellenőrzésen: az alagút resolvercímei jelen vannak a payloadban, a név nem volt gyorsítótárazva, egyetlen korábbi szabály sem egyezett már, az útvonallista lefedi az AAAA-útvonalat, és az alkalmazás az alagút hatókörén belül van. Ha mind az öt teljesül, a szabály teszi a dolgát, és a hiba valahol messzebb van az útvonalon.