VPN за Mac и PAC прокси: две решения, а не една настройка

Вашият Mac изтегля скрипт за политика и след това пита този скрипт през кой посредник да мине заявката, докато тунелът решава само как се достига до избрания хоп. И двата отговора попадат в един и същ сокет, затова заявка, която се проваля, след като и двете са успели, изглежда като една повреда, а всъщност са две. Разделянето на изтеглянето от избора и на избора от маршрута е по-голямата част от работата по тези тикети. Редът по-долу следва това, което macOS всъщност прави, с проверките, които правят всеки етап видим.

Къде адресът на PAC и проксито се разделят

Адрес като https://config.corp.example/proxy.pac именува документ за изтегляне, а този документ именува сървър, през който да минава трафикът. Поставянето на URL в поле за хост на прокси кара клиента да отвори прокси връзка към файлов сървър, който никога не очаква такава. Във файла има функция, която клиентът извиква при всяка заявка, а върнатата ѝ стойност е следващият хоп за тази единствена дестинация. Тази непрякост обяснява защо две машини в една и съща мрежова услуга могат да се държат различно, при все че и двете държат правилния URL. Тя обяснява и защо промяна в политиката влиза в сила, без някой да пипа самото прокси.

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

Скриптът трябва да бъде изтеглен, преди да реши каквото и да е

Изтеглянето на политиката изисква име, което да бъде разрешено, и маршрут до това, което обслужва файла, а свързан тунел не предполага нито едното. Ако хостът се разрешава само чрез частен DNS, резолверът, използван в този момент, решава дали изтеглянето може да започне. Ако хостът е в частен диапазон, маршрутът трябва да съществува от тази машина, а не от лаптопа на колега. Копие, кеширано по време на по-ранна сесия, скрива всичко това, докато кешът изтече или машината се рестартира.

Изпълнете трите проверки по-долу по ред и спрете при първия провал, защото етапите не споделят една причина. Заедно те показват дали политиката е конфигурирана, дали е достъпна и какво връща.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Първата команда отпечатва прокси речника за активната услуга, включително всеки URL за автоматично конфигуриране, който системата държи. Втората съобщава URL, прикачен към една именувана услуга, което има значение на лаптоп, който се движи между Wi-Fi и Ethernet. Третата изтегля файла без да го рендира, така че 404, изтичане на времето и отказ на резолвера остават различими. Ако последната команда върне скрипта, а приложенията все още се провалят, проблемът вече е отвъд изтеглянето.

Какво всъщност пропуска отговор DIRECT

Спецификацията PAC дава на клиента малък речник и DIRECT е една дума от него. Думата казва на клиента да заобиколи проксито за тази заявка и не казва нищо за това кой интерфейс ще използва сокетът след това. Директен сокет върху пълен тунел все пак излиза през VPN и все пак показва на дестинацията адреса на изхода на тунела.

Четенето на DIRECT като нещо извън VPN е грешката, която отвежда хората до грешен панел с настройки. Огледалната картина е също толкова честа, защото до частно прокси може да се стигне по разделен маршрут, докато останалата част от машината остава извън тунела. Това, което дестинацията съобщава тогава, принадлежи на собствения изход на проксито, който може да е в друга държава. Записването на очакването за един вътрешен хост и един публичен хост бързо го разкрива, тъй като скриптът често отговаря на двата различно. Щом знаете кой хоп е създал адреса, отчетът престава да бъде загадъчен.

Три отказа, които изглеждат като една страница с грешка

Политиката може да не се изтегли, избраното прокси може да е недостъпно, а заявка, която стигне до услугата, може да бъде отказана там. И трите идват като изтичане на времето или обща страница с грешка и нито едно не назовава етапа, който се е счупил. Записването на решението до грешката е това, което ги разделя. Двете проби по-долу проверяват хопа, който скриптът е избрал, по една за всеки клон, който може да върне.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Завършена връзка с проксито премества въпроса към удостоверяване или към собствените правила на проксито, които имат друг собственик. Завършена връзка с вътрешния хост без прокси по пътя изключва маршрута и сочи към правилата. И двете команди пренебрегват прокси речника на macOS, освен ако обвивката не експортира променливи за прокси, затова първо ги изчистете. Нито една проба не доказва другата и затова една страница с грешка заблуждава толкова дълго.

Какво да предадете с тикета

Изпратете активната мрежова услуга, URL на PAC, резултата от оценката за хостa, който се проваля, и етапа, на който се появи грешката. Тези четири позволяват на следващия човек да възпроизведе решението, вместо да гадае кой слой е участвал. Добавете състоянието на тунела към момента на теста, защото резултат, записан преди повторно свързване, е остарял. Пазете и ревизията на скрипта, тъй като файлът с правила се променя без предупреждение и вчерашният отговор може вече да не е актуален.

Запишете как се държи клиентът, когато скриптът не може да бъде изтеглен, защото реализациите се различават и решението за прокси не е общ прекъсвач за цялото устройство. Някои се връщат към директна връзка, а други се провалят затворено, и тази разлика променя дали прекъсването изглежда като счупено прокси или като работеща политика. Потвърдете поведението за точния клиент и версия, преди да разчитате на него по време на инцидент.