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

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

Тригерот и изборот на сообраќај се на различни слоеви

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

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

Имам лабораториски профил што се поврзува кога и да се побара нешто под внатрешен домен, но насочува само една /16 во тунелот. Го прави точно она што го вели неговиот payload, и е од типот профили што создаваат тикети: луѓето претпоставуваат дека поврзан тунел значи дека нивниот сообраќај е внатре.

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

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

Следуваат две последици. Профилот мора да именува 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 патека што листата рути ја покрива и апликацијата во опсегот на тунелот. Кога сите пет важат, правилото ја работи својата работа, а дефектот е понатаму по патеката.