Чаму 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.