Mac VPN и 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-у осим ако љуска извози прокси променљиве, па их прво очистите. Ниједна сонда не доказује другу, и зато једна страница грешке толико дуго заводи.

Шта предати уз тикет

Пошаљите активну мрежну услугу, PAC URL, резултат евалуације за хост који не ради и корак у којем се појавила грешка. Та четири омогућују следећој особи да репродукује одлуку уместо да нагађа који је слој био укључен. Додајте стање тунела у тренутку теста, јер је резултат забележен пре поновног повезивања застарео. Сачувајте и ревизију скрипте, јер се датотека правила мења без најаве и јучерашњи одговор можда више није актуелан.

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