Проксі для кожного профілю: DNS, автентифікація та відмови

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

Чотири незалежні запитання

Запис проксі зазвичай містить схему, адресу, порт та іноді посилання на облікові дані. Але він не відповідає на чотири запитання політики:

1. Охоплення: які запити й протоколи браузера використовують цей проксі?
2. Визначення адрес: хто визначає IP цільового хоста — пристрій чи проксі?
3. Автентифікація: які схеми підтримують обидві сторони й де зберігаються секрети?
4. Відмова: помилка зупиняє запит, перемикає на інший проксі чи дозволяє пряме з’єднання?

Сприйняття всього цього як одного перемикача «проксі ввімкнено» спричиняє більшість несподіванок. Chromium описує вибір як визначення маршруту на рівні URL: URL перетворюється на впорядкований список варіантів проксі ще до обов’язкового визначення адреси цілі. Винятки й резервні маршрути — частина цього рішення.

Що охоплює проксі профілю

Політика Google ProxySettings застосовується на рівні профілю Chrome. Вона підтримує прямий, системний, автоматично виявлений, фіксований і PAC-режим із явними винятками та обов’язковістю PAC.

Ця межа вужча за VPN або окремий мережевий простір ОС. Вона керує запитами мережевого контексту браузера, але автоматично не охоплює:

• API-запити самого настільного менеджера;
• окремий застосунок або засіб оновлення браузера;
• системний DNS і перевірки підключення;
• програму, відкриту із завантаженого файла;
• нативну допоміжну програму розширення;
• локальні сервіси, для яких діють неявні винятки loopback;
• протокол, який вибраний шлях проксі не підтримує.

Деякі компоненти можуть мати власну підтримку проксі. Її потрібно описувати й перевіряти окремо. Фраза «трафік профілю проходить через проксі» має називати процеси та протоколи, не створюючи враження маршрутизації всього пристрою.

Шлях одного HTTPS-запиту

Звичайний перехід HTTPS складається з кількох етапів.

1. Вибір маршруту

Браузер оцінює фіксовані правила, PAC-скрипт або системні налаштування. Виняток може вибрати прямий шлях. Список може містити основний проксі та альтернативи, зокрема DIRECT, якщо прямий резервний маршрут дозволено.

Chromium також має неявні винятки для localhost і link-local адрес. Це захищає локальні вебджерела від зовнішнього керування проксі, але потребує уточнення будь-якої заяви про «весь трафік».

2. Визначення адреси й підключення до проксі

Якщо адресу проксі задано іменем хоста, пристрій має визначити його IP і підключитися. Віддалений DNS цільового сайту не усуває цього початкового запиту. Його збій відрізняється від ситуації, коли проксі доступний, але не може визначити адресу сайту.

3. Автентифікація на проксі

HTTP-проксі, що вимагає облікових даних, зазвичай повертає 407 Proxy Authentication Required із запитом автентифікації. RFC 9110 визначає обмін і поля Proxy-Authenticate та Proxy-Authorization.

Chromium не використовує логін і пароль, вбудовані в ручні налаштування проксі. Документація вказує на звичайний механізм облікових даних браузера. Отже, менеджеру потрібна явна інтеграція підтримуваної автентифікації, а не обіцянка працездатності будь-якого рядка user:password@host.

4. Підключення до цілі

З HTTP-проксі Chromium передає визначення адреси цілі на сторону проксі. Для HTTPS браузер просить створити тунель CONNECT, а потім установлює наскрізне TLS-з’єднання із сайтом через нього.

Проксі все одно бачить ім’я цільового хоста й метадані з’єднання. Якщо ділянка браузер–проксі використовує звичайний HTTP, запит CONNECT та ім’я хоста на ній не захищено. HTTPS-проксі додає TLS на цій ділянці й приховує метадані від проміжних спостерігачів. Від самого проксі ціль не приховується.

Звичайний проксі не може читати вміст HTTPS-сторінки всередині тунелю. Перехоплення TLS — інша модель довіри: клієнт довіряє центру сертифікації, який дозволяє посереднику завершувати й створювати TLS заново. Це не можна непомітно прирівнювати до звичайного пересилання.

Хто виконує DNS, залежить від схеми

Документація Chromium описує відмінності:

Маршрут	Визначення адреси цілі	Важливе обмеження
Прямий або виняток	Резолвер пристрою чи браузера	Трафік іде без проксі профілю
HTTP-проксі	На проксі	Звичайний HTTP до проксі розкриває HTTP-запити; HTTPS використовує CONNECT
HTTPS-проксі	На проксі	Клієнт має перевіряти TLS-сертифікат проксі
SOCKS4	На клієнті	Лише IPv4; Chromium не має резервного SOCKS4a
SOCKS5	На проксі	Chromium використовує його для TCP URL-запитів і не підтримує автентифікації SOCKS5

RFC 1928 дозволяє передавати доменне ім’я в SOCKS5 та визначає кілька методів автентифікації. Можливість протоколу не гарантує реалізації в клієнті. Chromium передає ім’я цілі SOCKS5-проксі, але вбудований клієнт не підтримує жодного методу його автентифікації. Тому проксі з логіном і паролем може потребувати підтримуваного посередника або іншої схеми. Перевірте реалізацію до прийняття конфігурації.

DNS-over-HTTPS додає ще один рівень. Політика DnsOverHttpsMode розрізняє automatic, який може перейти на незахищений DNS, і secure, який завершує визначення адреси помилкою при відмові захищеного DNS. Політика документована на рівні браузера, тоді як ProxySettings — на рівні профілю. Це нагадує: слово «профіль» в одному параметрі не означає такої самої області всіх DNS-налаштувань.

Окремий процес браузера для кожного профілю може створювати вужчу фактичну межу, але це рішення реалізації. Перевіряйте окремо:

• визначення адреси самого проксі;
• визначення адреси цільового сайту;
• DNS прямих запитів і винятків;
• початкове підключення та резервну поведінку захищеного DNS;
• DNS компонентів поза мережевим контекстом профілю.

Автентифікація: сумісність і захист секретів

Chromium описує Basic, Digest, Negotiate та NTLM для HTTP-проксі. HTTPS-проксі додає захищений канал і може підтримувати клієнтські сертифікати. Вбудований клієнт Chromium не реалізує автентифікації SOCKS4 чи SOCKS5, хоча SOCKS5 визначає відповідні методи.

Навіть сумісна схема може бути небезпечною на неправильному транспорті. RFC 7617 пояснює: Basic лише кодує облікові дані в Base64 і потребує захищеного каналу, наприклад TLS. Basic через звичайний HTTP-проксі розкриває пароль тому, хто може спостерігати цю ділянку.

Менеджер має розділяти:

• несекретні метадані: схему, хост, порт і назву постачальника;
• посилання на секрет для служби запуску чи мережі;
• значення облікових даних у захищеному сховищі;
• очищений від секретів стан з’єднання для інтерфейсу й аудиту;
• діагностику, доступну лише через контрольований процес підтримки.

Звичайним екранам, журналам, API, експортам і автоматизації пароль проксі не потрібен. Оператору зазвичай достатньо знати, що вхід не вдався, яку схему запитано, якої адреси це стосується та чи відбувся перехід на інший маршрут.

Відмови та їхні ознаки

Відмова	Типова ознака	Що перевірити
Неправильна схема	Помилка TLS або узгодження протоколу	Чи не позначено HTTPS-проксі як HTTP або навпаки?
Не визначається адреса проксі	Збій до з’єднання з проксі	Який резолвер виконував початковий запит?
Порт недоступний	Тайм-аут або відмова з’єднання	Чи є далі інший проксі або DIRECT?
Непідтримувана автентифікація	Повторні 407 або запит входу	Чи реалізовано потрібну схему?
Неправильний або прострочений секрет	407 після надсилання даних	Чи отримано секрет за посиланням і чи приховано його у виводі?
Невалідний сертифікат HTTPS-проксі	Відмова захищеного з’єднання	Чи збережено перевірку сертифіката?
Проксі не визначає ціль	Помилка хоста або тунелю	Чи не повторив клієнт запит напряму?
CONNECT заборонено	HTTPS-перехід до цілі не працює	Чи розглядається відмова як політика, а не дозвіл обходу?
PAC недоступний	Затримка або зміна маршруту	Чи обов’язковий PAC, чи можливий прихований DIRECT?
Надто широкий виняток	Деякі сайти йдуть напряму	Чи враховано хост, піддомен, порт і неявні правила?
WebRTC використовує інший інтерфейс	Медіатрафік іде іншим шляхом	Чи заборонено UDP поза проксі?
Старе з’єднання пережило зміну	Попередній маршрут тимчасово активний	Чи закриваються з’єднання або перезапускається профіль?
Надмірна діагностика	URL, хости чи секрети у файлі підтримки	Які режим приховування та строк зберігання?

Резервний вибір Chromium має стан. Проксі з помилкою з’єднання може тимчасово позначатися несправним і переміщуватися за інші записи. Якщо серед них є DIRECT, наступні запити можуть іти без проксі. Відмова CONNECT обробляється інакше, бо може означати свідому політику цілі, а не недоступність проксі.

Особливо перевіряйте PAC. За документацією Chromium, недоступний PAC може непомітно спричинити прямий маршрут, якщо не є обов’язковим. Політика ProxySettings має ProxyPacMandatory саме для заборони такого переходу.

WebRTC і UDP потребують окремого рішення

Сторінка може використовувати WebRTC-шляхи, відмінні від звичайних HTTP/HTTPS-запитів. Типова політика WebRtcIPHandling може використовувати всі доступні інтерфейси. Режим disable_non_proxied_udp обмежує WebRTC протоколом TCP на публічному інтерфейсі, якщо налаштований проксі не підтримує UDP.

Це політика профілю, але окремий засіб контролю. Вона може зменшити якість медіа або порушити сценарій із прямим UDP. Вибирайте й перевіряйте компроміс явно. Успішне завантаження сторінки не доводить повного утримання трафіку в проксі.

Визначте пріоритет при відмові

Прямий резервний маршрут може бути доречним для загального перегляду, де важлива доступність. Він небезпечний, якщо повноваження, приватність або достовірність регіонального тесту залежать від конкретного вихідного маршруту.

Політика має називати поведінку:

• Обов’язковий проксі: зупиняти відповідні запити, якщо шлях недоступний.
• Погоджений набір: пробувати лише визначені альтернативи з рівнозначними правилами.
• Прямий резервний маршрут дозволено: показувати зміну та записувати подію без секретів.
• Явний виняток: описати категорію цілей і потребу прямого доступу.

Інтерфейс має показувати маршрут до запуску й після збою. Непомітна заміна проксі прямим шляхом перетворює мережеву помилку на порушення коректності: робота здається успішною, але відбувається не тим шляхом.

Безпечна матриця перевірки

Використовуйте власні або дозволені для перевірки адреси й DNS-зони. До запуску запишіть очікувані результати.

1. Зіставте заявлену схему з реальним транспортом проксі.
2. Перевірте HTTP, HTTPS, WebSocket і потрібний WebRTC.
3. Спостерігайте вихідну IP-адресу на контрольованій цілі.
4. Визначте резолвер запиту цілі та резолвер адреси проксі.
5. Завершіть строк тестового секрету й перевірте відсутність його відкритого значення в інтерфейсі, журналах та автоматизації.
6. Зробіть тестовий проксі недоступним і перевірте блокування або погоджений резервний шлях.
7. Забороніть одну контрольовану ціль CONNECT і переконайтеся, що відмова не перетворюється на прямий доступ.
8. Зробіть тестовий PAC недоступним і перевірте обов’язковий режим.
9. Перевірте потрібні точні, піддоменні, локальні, link-local, IPv4 та IPv6 винятки.
10. Змініть проксі за активних з’єднань і визначте момент застосування нового маршруту.
11. Запишіть лише потрібну діагностику, потім перевірте зберігання й видалення.

Рекомендації Chromium NetLog розглядають мережеві журнали як питання приватності й безпеки. Режими з приховуванням можуть виключати чутливі поля, а детальніші — містити cookies або заголовки автентифікації. Поводьтеся з файлом підтримки за фактичним режимом запису, а не за його назвою.