Kā Apple VPN On Demand domēna noteikumi palaiž tuneli

Tunelis atveras, kad pieprasāt vienu iekšēju nosaukumu, un paliek aizvērts, kad nākamajai lietotnei tas nepieciešams tikpat ļoti. Tā nav lietotnes kļūda; tā ir domēna noteikuma forma. Apple on-demand konfigurācija apraksta nosacījumus savienojuma izveidei, un šo nosacījumu domēna forma pajautā sistēmas resolverim jautājumu, pirms kustas pat viens pakets. Divi jautājumi tiek pastāvīgi sajaukti: kad tunelim jāpaceļas un ko tunelis pārvadā, kad tas jau pastāv. Pirmais ir trigeris, otrais ir maršrutu un resolvera politika, un viens profils parasti iestata abus tajā pašā payload, tāpēc pareizs domēna noteikums joprojām var atstāt jūs nepareizajā tīklā.

Trigeris un trafika izvēle atrodas dažādos slāņos

On-demand noteikums dzīvo VPN payload on-demand vārdnīcā: sakārtots noteikumu saraksts, katram ir darbība un atbilstības nosacījumu kopa. Sistēma tos novērtē, kad mainās savienojamība vai kad kaut kas mēģina sasniegt tīklu, un darbība izlemj, vai tunelis tiek pacelts, novērtēts, atvienots vai ignorēts. Tas viss notiek platformas tīkla slānī, pirms jūsu lietotnei ir socket.

Tas, kas seko, ir atsevišķa atslēgu grupa: tuneļa IPv4 un IPv6 iestatījumi, tā iekļautie un izslēgtie maršruti, DNS serveru adreses un iOS un iPadOS gadījumā kartējums pa lietotnēm, kas nosaka, kuras lietotnes vispār drīkst izmantot tuneli. Profils var savienot plašu trigeri ar šauru maršrutu vai šauru trigeri ar noklusējuma maršrutu. Lasi tikai vienu pusi, un otra izskatīsies kā darbības traucējums.

Man ir laboratorijas profils, kas savienojas, kad vien tiek pieprasīts kaut kas zem iekšēja domēna, bet tunelī novirza tikai vienu /16. Tas dara tieši to, kas teikts tā payload, un tas ir arī profila veids, kas rada biļetes: cilvēki pieņem, ka pievienots tunelis nozīmē, ka viņu trafiks ir tajā.

Ko domēna noteikums patiešām jautā resolverim

Noteikuma domēna forma, ko bieži sauc par connect-if-needed, nepārbauda pakešu payload un nevēro URL. Kad nosaukums tiek atrisināts, sistēma to salīdzina ar noteikuma domēniem un atbilstības gadījumā jautā, vai šo nosaukumu var atrisināt caur DNS serveriem, ko nodrošina tunelis. Ja tuneļa resolvers atbild, nosaukums tiek uzskatīts par iekšēju un savienojums sākas. Ja tā vietā atbild vietējais resolvers, nosaukums tiek uzskatīts par ārēju un tunelis neparādās. Apple izvietošanas pārskats to apraksta kā tīkla noteikšanu un pēc tam savienojuma novērtēšanu.

No tā izriet divas sekas. Profilam jānorāda DNS serveri tuneļa iekšienē; domēna noteikumam bez tuneļa resolvera nav ar ko salīdzināt, tāpēc novērtējums nevar dot gaidīto atbilstību. Un vaicājumam jāsasniedz sistēmas resolvers. Lietotne vai pārlūks, kas darbo savu šifrēto DNS, paplašinājums, kas atbild lokāli, vai savienojums ar burtisku adresi nekad nerada to nosaukuma atrisinājumu, uz kuru noteikums gaidīja. Viena no garākajām pēcpusdienām, ko esmu pavadījis, beidzās, kad atklāju, ka klients tuneļa priekšā izmantoja DNS over HTTPS.

Kešatmiņa arī noņem trigeri. Uz jau kešatmiņā esošu nosaukumu var atbildēt bez pārbaudes, kas būtu palaidusi tuneli, tāpēc noteikums, kas vakar strādāja, neizdodas pēc restartēšanas vai pēc tam, kad tunelis kādu laiku ir bijis augšā. macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder atiestata stāvokli; iOS lidmašīnas režīma ieslēgšana un izslēgšana vai ierīces restartēšana dod salīdzināmu tīru sākumu.

Atbilstības apjoms: nosaukumi, lietotnes un tīkli

Domēna atbilstība ir viens veids starp vairākiem. Noteikums var atbilst arī saskarnes tipam (Wi-Fi, mobilais, Ethernet) un konkrētam SSID, un ieraksti pa lietotnēm vai Safari domēnam saista tuneli ar vienu darbplūsmu. Šī saite izskaidro dīvaino pieredzi, kad tikai viena lietotne uzvedas citādi nekā visas pārējās: pārējās lietotnes ir ārpus tuneļa apjoma, tāpēc tās turpina izmantot vietējo ceļu pat tad, kad tuneļa ikona rāda savienojumu.

Secība ir svarīgāka, nekā cilvēki sagaida. Noteikumi tiek novērtēti pēc kārtas, un pirmais atbilstošais dod darbību, tāpēc plašs noteikums savienoties-ar-jebkuru-Wi-Fi, novietots virs šaura domēna noteikuma, klusi uzvarēs un padarīs domēna noteikumu nepārbaudāmu. Pirms pārrakstīt domēnu sarakstu, apstipriniet, ka neviens iepriekšējais noteikums jau nav atbildis.

Tāpēc always-on nav tikai stingrāks on-demand noteikums. Always-on izpilde ir atsevišķs izvietošanas režīms ar savām uzraudzības un pārvaldības prasībām; tas tur tuneli atvērtu, nevis reaģē uz nosaukumu. Ja jums vajag tuneli, kas nekad nekrīt, domēna noteikums ir nepareizais rīks.

Kļūmju režīmi, kas imitē salauztu noteikumu

Lielākā daļa ziņojumu, ka domēna noteikums nedarbojas, nonāk vienā no piecām vietām, un tikai pēdējā no tām ir noteikuma teksts.

Captive portāli ir pelnījuši savu rindu, jo viesnīcu un lidostu Wi-Fi pārtver tieši to vaicājumu, no kura noteikums ir atkarīgs. Kamēr portāls neielaiž ierīci, tuneļa DNS serveris nav sasniedzams, pārbaude neizdodas, un kļūme izskatās kā nepareizi uzrakstīts domēns. Autentifikācija ir otrs klusais gadījums: noteikums var nostrādāt, tunelis var sākt savienoties, un savienojums mirst uz beigušos sertifikātu vai uzvedni, kas parādās citā ekrānā.

IPv6 rada variantu, ko viegli nepareizi diagnosticēt. Nosaukumam ar abām adrešu saimēm vispirms var atbildēt no AAAA ieraksta, kamēr tuneļa maršrutu sarakstā ir tikai IPv4. Viens pārlūks izdodas, cits neizdodas, un domēnu saraksts ir pilnīgi nevainīgs.

Pārbaudiet ar reālu pieprasījumu, šādā secībā

Izlasiet politiku, pirms minēt. macOS sudo profiles show -type configuration izdrukā instalētos profilus, tostarp VPN payload, scutil --nc list parāda pakalpojuma stāvokli, un scutil --nc show <service> izdrukā on-demand vārdnīcu, ko sistēma izmanto. Pārvaldītā iPhone vai iPad tas pats payload nāk no pārvaldības konsoles vai MDM atskaites. Tīkla žurnāli ir pieejami ar log stream --predicate 'subsystem == "com.apple.networkextension"' macOS un caur ierīces konsoli, kad tālrunis ir pievienots.

Pēc tam pārbaudiet ar resursdatora nosaukumu, kas šajā sesijā vēl nav ticis vaicāts. Izvēlieties nosaukumu tuneļa DNS zonā, par kuru zināt, ka tas tiek atrisināts iekšēji, pieprasiet to vienreiz un vērojiet, vai tunelis parādās. Palaidiet to pašu vaicājumu divreiz: otrais mēģinājums izmanto kešatmiņas ceļu, un atšķirība starp abiem pasaka, vai trigeris ir atrisināšana vai maršrutēšana.

Kad tunelis ir augšā, pārbaudiet abus slāņus atsevišķi. netstat -rn -f inet un netstat -rn -f inet6 rāda, uz kurieni vērsts katrs prefikss, scutil --dns rāda resolveru secību un to, kura saskarne pieder katram resolveram, un nettop -m route rāda, kura saskarne pārvadāja baitus. Ja tunelis ir augšā un resolvers ir pareizs, bet resurss joprojām neizdodas, pārtrauciet rediģēt noteikumu; pārbaudiet servera puses autorizāciju un atgriešanās maršrutu.

Kad noteikums pieder kādam citam

Ja tunelis atkal parādās pēc atvienošanas, noteikums parasti pieder profilam, nevis lietotnei: MDM virzīta konfigurācija, palicis personīgais profils vai cita klienta instalēts profils. sudo profiles show -type configuration un on-demand atslēgu meklēšana to sašaurinās, un noņemšanas ceļš ir profils, nevis slēdzis izvēļņu joslā. Pakalpojuma ieraksta vai lietotnes dzēšana atstāj noteikumu, un nākamā instalācija to atkal manto.

Viens tests izšķir īpašumtiesības: atvienojiet, pagaidiet, vēlreiz pieprasiet iekšējo nosaukumu. Ja tunelis atgriežas, trigeris darbojas kā projektēts, un atklātais jautājums ir, kas to pārvalda un vai šis apjoms ir tas, ko vēlaties.

Pirms ziņot par to kā kļūdu, iziet tos pašus piecus pārbaudījumus: tuneļa resolvera adreses ir payload, nosaukums nebija kešatmiņā, neviens iepriekšējais noteikums jau nebija atbildis, maršrutu saraksts aptver AAAA ceļu, un lietotne ir tuneļa apjomā. Kad visi pieci ir spēkā, noteikums dara savu darbu, un kļūda ir tālāk ceļā.