Mac VPN және PAC проксиі: бір параметр емес, екі шешім
PAC файлы әр сұранысқа прокси таңдайды, VPN болса маршрут таңдайды. Жүктеуді, таңдауды және сокетті бақылаңыз және DIRECT-ті офлайн деп оқуды тоқтатыңыз.
Сіздің 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-ын, сәтсіз хост үшін бағалау нәтижесін және қате пайда болған кезеңді жіберіңіз. Осы төртеуі келесі адамға қай қабат қатысқанын болжаудың орнына шешімді қайта жаңғыртуға мүмкіндік береді. Тест сәтіндегі туннель күйін қосыңыз, өйткені қайта қосылу алдында алынған нәтиже ескірген. Скрипт ревизиясын да сақтаңыз, өйткені саясат файлы ескертусіз өзгереді және кешегі жауап енді өзекті болмауы мүмкін.
Скриптті алу мүмкін болмаған кезде клиенттің қалай әрекет ететінін жазыңыз, өйткені іске асырулар әртүрлі және прокси шешімі бүкіл құрылғының өшіргіші емес. Кейбіреулер тікелей қосылысқа оралады, басқалары жабық күйде сәтсіз болады, және бұл айырмашылық үзілістің сынған прокси сияқты немесе жұмыс істеп тұрған саясат сияқты көрінуін өзгертеді. Оқиға кезінде оған сүйенбес бұрын нақты клиент пен нұсқа үшін мінез-құлықты растаңыз.