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

Што да се предаде со тикетот

Испратете ја активната мрежна услуга, URL-то на PAC, резултатот од проценката за домаќинот што не успева и фазата во која се појавила грешката. Овие четири му овозможуваат на следниот човек да ја репродуцира одлуката наместо да претпоставува кој слој бил вклучен. Додајте ја состојбата на тунелот во моментот на тестот, бидејќи резултатот забележан пред повторно поврзување е застарен. Зачувајте ја и ревизијата на скриптата, бидејќи датотеката со политика се менува без известување, а вчерашниот одговор може веќе да не е актуелен.

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