Як правілы даменаў Apple VPN On Demand запускаюць тунель

Тунэль адкрываецца, калі вы запытваеце адно ўнутранае імя, і застаецца зачыненым, калі наступнай праграме яно трэба гэтак жа. Гэта не памылка ў праграме; гэта форма правіла дамена. Канфігурацыя on-demand ад Apple апісвае ўмовы для стварэння злучэння, а даменная форма гэтых умоў задае сістэмнаму рэзалверу пытанне яшчэ да таго, як зрушыцца хоць адзін пакет. Два пытанні пастаянна блытаюць: калі тунэль павінен узнікнуць і што тунэль нясе, калі ўжо існуе. Першае — гэта трыгер, другое — палітыка маршрутаў і рэзалвера, і адзін профіль звычайна задае абодва ў адной карыснай нагрузцы, таму правільнае правіла дамена можа пакінуць вас у няправільнай сетцы.

Трыгер і выбар трафіку знаходзяцца на розных узроўнях

Правіла on-demand жыве ў слоўніку on-demand карыснай нагрузкі VPN: упарадкаваны спіс правілаў, кожнае з дзеяннем і наборам умоў супадзення. Сістэма ацэньвае іх, калі змяняецца злучэнне або калі нешта спрабуе дасягнуць сеткі, і дзеянне вырашае, ці тунэль паднімаецца, ацэньваецца, адключаецца або ігнаруецца. Усё гэта адбываецца ў сеткавым пласце платформы, да таго як у вашай праграмы з’явіцца сокет.

Тое, што адбываецца пасля, — асобная група ключоў: налады IPv4 і IPv6 тунэля, яго ўключаныя і выключаныя маршруты, адрасы DNS-сервераў, а на iOS і iPadOS — суаднясенне па праграмах, якое вырашае, якія праграмы наогул могуць карыстацца тунэлем. Профіль можа спалучыць шырокі трыгер з вузкім маршрутам або вузкі трыгер з маршрутам па змаўчанні. Прачытайце толькі адну палову — і другая палова будзе выглядаць як няспраўнасць.

У мяне ёсць лабараторны профіль, які падключаецца, калі запытваецца што-небудзь унутры ўнутранага дамена, але накіроўвае ў тунэль толькі адну /16. Ён робіць менавіта тое, што сказана ў яго карыснай нагрузцы, і гэта таксама той тып профілю, які спараджае заяўкі: людзі мяркуюць, што падключаны тунэль азначае, што іх трафік унутры яго.

Што правіла дамена насамрэч пытае ў рэзалвера

Даменная форма правіла, якую часта называюць connect-if-needed, не правярае карысную нагрузку пакетаў і не назірае за 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, scutil --nc list паказвае стан службы, а scutil --nc show <service> друкуе слоўнік on-demand, які выкарыстоўвае сістэма. На кіраваным iPhone або iPad тая ж нагрузка прыходзіць з кансолі кіравання або справаздачы 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 звузіць яго, і шлях выдалення — гэта профіль, а не перамыкач у радку меню. Выдаленне запісу службы або праграмы пакідае правіла, і наступная ўстаноўка зноў яго атрымлівае ў спадчыну.

Адзін тэст вырашае пытанне ўласнасці: адключыце, пачакайце, зноў запытайце ўнутранае імя. Калі тунэль вернецца, трыгер працуе як задумана, і адкрытае пытанне — хто ім кіруе і ці той гэта абсяг, які вам патрэбны.

Перш чым падаваць гэта як памылку, прайдзіце тыя ж пяць праверак: адрасы рэзалвера тунэля прысутнічаюць у нагрузцы, імя не было закэшавана, ніводнае папярэдняе правіла ўжо не супала, шлях AAAA пакрыты спісам маршрутаў, і праграма ўнутры абсягу тунэля. Калі ўсе пяць выконваюцца, правіла робіць сваю справу, а няспраўнасць — далей на шляху.