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, результат оцінювання для хоста, що падає, і етап, на якому з'явилася помилка. Ці чотири дають наступній людині змогу відтворити рішення, а не вгадувати, який шар був задіяний. Додайте стан тунелю на момент тесту, бо результат, знятий до перепідключення, застарілий. Збережіть і ревізію скрипта, адже файл політики змінюється без попередження, і вчорашня відповідь може вже не бути актуальною.

Запишіть, як клієнт поводиться, коли скрипт неможливо завантажити, бо реалізації різняться, а рішення проксі не є загальним вимикачем пристрою. Деякі повертаються до прямого з'єднання, інші відмовляють закрито, і ця різниця змінює, чи виглядає збій як зламаний проксі, чи як робоча політика. Підтвердьте поведінку для точного клієнта й версії, перш ніж покладатися на неї під час інциденту.