Чому 403 із VPN-сайту — не збій проксі

Користувачі вимикають VPN, отримують 403 на внутрішньому сайті й повідомляють, що проксі зламано. Цю сторінку можуть створити три різні речі: джерело відхилило запит, прямий проксі відмовився відкривати тунель або проксі зажадав власні облікові дані. Кожна з них — правильна відповідь на інше питання, і зведення їх в одну загальну сторінку збою знищує єдиний доказ, який ви маєте. Розкладіть відмову за компонентом, який її створив, а потім порівняйте мережевий шлях, який кожен компонент насправді використовує.

Назвіть компонент, що створив 403

Код стану HTTP належить стороні, яка його надіслала. Коли джерело повертає 403, воно розібрало запит і вирішило, що викликач може не мати ресурсу, — це відповідь про авторизацію, а не проблема транспорту. Коли прямий проксі відповідає 403 на CONNECT, він відмовився будувати тунель узагалі, і нічого вище не було задіяно. Коли він відповідає 407, він хоче власні облікові дані, які не мають нічого спільного з входом у застосунок.

RFC 9110 визначає ці ролі, включно з викликом, характерним для проксі. Прочитайте власний стан відповіді та будь-який заголовок Proxy-Authenticate перед читанням тіла, бо дружня HTML-сторінка помилки зазвичай приховує, який компонент її написав.

Що тунель CONNECT приховує від передавання байтів

Після того як проксі повертає 200 на CONNECT, він передає байти, а браузер підтримує власну сесію TLS із джерелом. Тому проксі, що передає байти, не може прочитати зашифрований 403 усередині цієї сесії й ніколи не стає автором відмови. Відмова до відкриття тунелю — зовсім інша подія, створена на рівень нижче.

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

Практичний наслідок: перш ніж тлумачити 403, треба знати, яку з трьох форм ви запускаєте. Додавання правил HTTP-інспекції до потокового проксі не дає йому видимості, а очікування, що передавання байтів пояснить відмову джерела, відправить вас у неправильний журнал.

Порівняйте шлях виходу проксі з адресою тунелю браузера

Браузер, підключений до VPN, не переносить окремий проксі-сервер у цей тунель автоматично. Джерело бачить адресу виходу проксі, і якщо проксі досі виходить через локальний маршрут за замовчуванням, захищений сайт бачить адресу, якій ніколи не налаштовували довіру. Внутрішня VPN-адреса на ноутбуці невидима для цього джерела. Це найчастіша причина, чому робочий тунель усе ще дає 403 від сайту, який поводиться правильно щодо всіх інших.

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

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Перший запит показує, що джерело відповідає на вашу власну адресу, другий — що воно відповідає на адресу проксі. Збіжна пара 403 вказує на правила авторизації джерела; 200, за яким іде 403, вказує на шлях проксі. Запитайте власника джерела, які вихідні адреси набір правил справді допускає, замість того щоб припускати, що пул VPN включено.

Перевірте кожну межу запитом, який її ізолює

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

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Якщо це виводить 200 для CONNECT, а потім TLS-рукостискання, допуск проксі гаразд, і пізніший 403 прийшов від джерела. Якщо виводиться 407, надайте облікові дані проксі через --proxy-user і повторіть, перш ніж робити будь-який висновок про сайт. Якщо виводиться 403 у рядку CONNECT, власний список дозволів проксі — це межа, яку треба дослідити, а застосунок тут не задіяний.

Тримайте облікові дані поза історією оболонки й поза вставленими розшифровками. Пароль проксі, набраний у командному рядку, видно іншим локальним користувачам, а зафіксований слід CONNECT з обліковими даними гірший за його відсутність.

Тримайте вердикт читабельним, а не переписуйте сторінку

Коли ви знаєте, який компонент відмовив, збережіть цю відповідь. Зворотний проксі, який перейменовує 403 джерела на тайм-аут 504 або замінює його сторінкою успіху, приховує рішення про авторизацію за історією доступності й відправляє наступного відповідального до неправильної команди. Власні сторінки помилок хороші, коли зберігають статус і додають контекст.

Кешування заслуговує на таку саму увагу. RFC 9111 регулює, як спільні кеші можуть повторно використовувати відповіді, і відмова, створена для одного викликача, не повинна передаватися іншому як дозвіл. Якщо відповіді про відмову взагалі зберігаються, тримайте їх приватними й обмеженими, і ніколи не додавайте публічне правило свіжості лише для зменшення трафіку вгору.

Завершіть письмовим вердиктом, який називає компонент, створений ним статус і вихідну адресу, яку побачило джерело. Запишіть точний запит, чинні налаштування проксі й час, щоб наступний звіт можна було зіставити з тими самими доказами, а не виводити заново з пам'яті. Цей запис відповідає на наступний звіт за секунди й не дає знову діагностувати той самий 403 як збій VPN.