Како Apple VPN On Demand доменска правила покрећу тунел

Тунел се отвара када затражите једно интерно име, а остаје затворен када га следећа апликација треба једнако јако. То није грешка у апликацији; то је облик доменског правила. Apple on-demand конфигурација описује услове за успостављање везе, а доменски облик тих услова пита системски резолвер питање пре него што се помери и један пакет. Два питања се стално мешају: када тунел треба да се подигне и шта тунел носи када постоји. Прво је окидач, друго је политика рута и резолвера, а један профил обично поставља обоје у истом payload-у, због чега вас исправно доменско правило ипак може оставити на погрешној мрежи.

Окидач и избор саобраћаја леже на различитим слојевима

On-demand правило живи у on-demand речнику VPN payload-а: уређена листа правила, свако са акцијом и скупом услова подударања. Систем их процењује када се повезаност промени или када нешто покуша да дође до мреже, а акција одлучује да ли се тунел подиже, процењује, прекида или игнорише. Све се то дешава у мрежном слоју платформе, пре него ваша апликација добије socket.

Оно што следи је одвојена група кључева: IPv4 и IPv6 поставке тунела, његове укључене и искључене руте, адресе DNS сервера и на iOS-у и iPadOS-у мапирање по апликацијама које одлучује које апликације уопште смеју да користе тунел. Профил може да упари широки окидач са уском рутом или уски окидач са подразумеваном рутом. Прочитајте само једну половину и друга ће изгледати као квар.

Имам лабораторијски профил који се повезује кад год се затражи било шта под интерном доменом, али у тунел усмерава само једну /16. Ради тачно оно што његов payload каже, а то је и врста профила која ствара тикете: људи претпостављају да повезан тунел значи да је њихов саобраћај унутра.

Шта доменско правило заправо пита резолвер

Доменски облик правила, често назван connect-if-needed, не прегледа payload пакета нити посматра URL-ове. Када се име разрешава, систем га упоређује са доменима у правилу и, при подударању, пита може ли се то име разрешити преко DNS сервера које тунел пружа. Ако резолвер тунела одговори, име се сматра интерним и веза се покреће. Ако уместо тога одговори локални резолвер, име се третира као екстерно и тунел се не појављује. Appleov преглед имплементације то описује као откривање мреже након којег следи процена везе.

Две последице следе. Профил мора да наведе DNS сервере унутар тунела; доменско правило без резолвера тунела нема шта да упоређује, па процена не може да да подударање које очекујете. И претрага мора да стигне до системског резолвера. Апликација или прегледач који покреће сопствени шифровани DNS, екстензија која одговара локално или веза на дословну адресу никада не производе разрешавање имена које је правило чекало. Једно од најдужих поподнева које сам провео завршило се када сам открио да клијент испред тунела користи DNS over HTTPS.

Кеширање такође уклања окидач. Име које је већ у кешу може бити одговорено без сонде која би покренула тунел, па правило које је јуче радило не успева након поновног покретања или након што је тунел неко време био подигнут. На macOS-у sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ресетује стање; на iOS-у пребацивање авионског режима или поновно покретање уређаја даје вам упоредив чист почетак.

Обим подударања: имена, апликације и мреже

Подударање домена један је тип међу неколико. Правило може да одговара и типу интерфејса (Wi-Fi, мобилни, Ethernet) и одређеном SSID-у, а уноси по апликацији или Safari домени везују тунел за један радни ток. Та веза објашњава чудно искуство у којем се само једна апликација понаша другачије од свега осталог: друге апликације су изван обима тунела, па настављају да користе локалну путању чак и док икона тунела показује повезаност.

Редослед је важнији него што људи очекују. Правила се процењују редом и прво које се подудари даје акцију, па широко правило повежи-се-на-било-који-Wi-Fi постављено изнад уског доменског правила тихо побеђује и чини доменско правило нетстабилним. Пре него што препишете листу домена, потврдите да се ниједно раније правило већ није подударило.

Зато always-on није само строже on-demand правило. Спровођење always-on је одвојен начин имплементације са сопственим захтевима за надзор и управљање; држи тунел отвореним уместо да реагује на име. Ако вам треба тунел који никада не пада, доменско правило је погрешан алат.

Начини квара који опонашају покварено правило

Већина извештаја да доменско правило не ради пада на једно од пет места, а само је последње од њих текст правила.

Captive портали заслужују свој ред, јер Wi-Fi у хотелима и аеродромима пресреће управо ону претрагу од које правило зависи. Док портал не пусти уређај, DNS сервер тунела је недоступан, сонда не успева, а квар изгледа као погрешно написана домена. Аутентификација је други тихи случај: правило може да се активира, тунел може почети да се повезује, а веза умире на истеклом сертификату или на упиту који се појави на другом екрану.

IPv6 ствара варијанту коју је лако погрешно дијагностиковати. На име са обе породице адреса може се прво одговорити из AAAA записа, док листа рута тунела носи само IPv4. Један прегледач успева, други не, а листа домена је потпуно невина.

Тестирајте стварним захтевом, овим редом

Прочитајте политику пре него што нагађате. На macOS-у sudo profiles show -type configuration исписује инсталиране профиле укључујући VPN payload, scutil --nc list приказује стање услуге, а scutil --nc show <service> исписује on-demand речник који систем користи. На надгледаном iPhone-у или iPad-у исти payload долази из управљачке конзоле или MDM извештаја. Мрежни дневници доступни су са log stream --predicate 'subsystem == "com.apple.networkextension"' на macOS-у и преко конзоле уређаја када је телефон прикључен.

Затим тестирајте са именом хоста које није било упитано раније у сесији. Одаберите име у DNS зони тунела за које знате да се разрешава интерно, затражите га једном и гледајте да ли се тунел појављује. Покрените исту претрагу двапут: други покушај вежба путању кеша, а разлика између њих говори вам да ли је окидач разрешавање или рутирање.

Након што се тунел подигне, проверите два слоја одвојено. netstat -rn -f inet и netstat -rn -f inet6 показују куда води сваки префикс, scutil --dns показује редослед резолвера и који интерфејс поседује који резолвер, а nettop -m route показује који је интерфејс пренео бајтове. Ако је тунел подигнут и резолвер исправан, али ресурс и даље не успева, престаните да уређујете правило; проверите ауторизацију на страни сервера и повратну руту.

Када правило припада некоме другом

Ако се тунел поново појави након што га искључите, правило обично припада профилу, а не апликацији: конфигурација гурнута путем MDM-а, заостали лични профил или профил који је инсталирао други клијент. sudo profiles show -type configuration плус претрага on-demand кључева то ће сузити, а пут уклањања је профил, а не прекидач у траци менија. Брисање уноса услуге или апликације оставља правило иза себе, а следећа инсталација га поново наслеђује.

Један тест решава питање власништва: искључите, сачекајте, поново затражите интерно име. Ако се тунел врати, окидач ради како је дизајниран, а отворено питање је ко њиме управља и да ли је тај обим оно што желите.

Пре него што ово пријавите као грешку, прођите кроз истих пет провера: адресе резолвера тунела присутне у payload-у, име које није било кеширано, ниједно раније правило које се већ подударило, AAAA путања коју листа рута покрива и апликација унутар обима тунела. Када свих пет важи, правило ради свој посао, а квар је даље дуж путање.