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

Тунелът се отваря, когато поискате едно вътрешно име, и остава затворен, когато следващото приложение се нуждае от него също толкова. Това не е дефект в приложението; това е формата на правило за домейн. Конфигурацията on-demand на Apple описва условия за установяване на връзка, а домейн формата на тези условия задава въпрос на системния resolver, преди да се е преместил дори един пакет. Два въпроса постоянно се бъркат: кога тунелът трябва да се вдигне и какво носи тунелът, след като съществува. Първото е тригер, второто е политика за маршрути и resolver, и един профил обикновено задава и двете в един и същ payload, поради което правилно правило за домейн все още може да ви остави в грешната мрежа.

Тригерът и изборът на трафик са на различни слоеве

Правилото on-demand живее в речника on-demand на VPN payload: подреден списък от правила, всяко с действие и набор от условия за съвпадение. Системата ги оценява, когато свързаността се промени или когато нещо се опита да достигне мрежата, и действието решава дали тунелът се вдига, оценява, прекъсва или игнорира. Всичко това се случва в мрежовия слой на платформата, преди приложението ви да има сокет.

Това, което се случва след това, е отделна група ключове: настройките IPv4 и IPv6 на тунела, включените и изключените му маршрути, адресите на DNS сървърите и на iOS и iPadOS съпоставянето по приложения, което решава кои приложения изобщо могат да използват тунела. Профилът може да съчетае широк тригер с тесен маршрут или тесен тригер с маршрут по подразбиране. Прочетете само едната половина и другата ще изглежда като неизправност.

Поддържам лабораторен профил, който се свързва, когато бъде поискано нещо под вътрешен домейн, но насочва само една /16 в тунела. Той прави точно това, което казва payload-ът му, и е също от типа профили, които пораждат тикети: хората предполагат, че свързан тунел означава, че трафикът им е вътре в него.

Какво всъщност правилото за домейн пита resolver-а

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

Следват две последствия. Профилът трябва да посочва DNS сървъри вътре в тунела; правило за домейн без resolver на тунела няма какво да сравни, така че оценката не може да даде очакваното съвпадение. И търсенето трябва да достигне до системния resolver. Приложение или браузър, който пуска собствен криптиран 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 показва реда на resolver-ите и кой интерфейс притежава всеки resolver, а nettop -m route показва кой интерфейс е пренесъл байтовете. Ако тунелът е вдигнат и resolver-ът е правилен, но ресурсът все още не работи, спрете да редактирате правилото; проверете оторизацията от страна на сървъра и обратния маршрут.

Когато правилото принадлежи на някой друг

Ако тунелът се появи отново след прекъсване, правилото обикновено принадлежи на профил, а не на приложение: конфигурация, изпратена чрез MDM, остатъчен личен профил или профил, инсталиран от друг клиент. sudo profiles show -type configuration плюс търсене на ключовете on-demand ще го стесни и пътят за премахване е профилът, а не превключвателят в лентата с менюта. Изтриването на записа за услугата или на приложението оставя правилото и следващата инсталация отново го наследява.

Един тест решава въпроса за собствеността: прекъснете, изчакайте, поискайте вътрешното име отново. Ако тунелът се върне, тригерът работи както е проектиран и откритият въпрос е кой го управлява и дали този обхват е това, което искате.

Преди да го докладвате като дефект, преминете през същите пет проверки: адреси на resolver на тунела, налични в payload-а, име, което не е било кеширано, никое по-ранно правило, което вече е съвпаднало, AAAA път, който списъкът с маршрути покрива, и приложението в обхвата на тунела. Когато и петте са налице, правилото си върши работата и неизправността е някъде по-нататък по пътя.