VPN сайтынан келген 403 эмне үчүн проксинин бузулушу эмес

Колдонуучулар VPNды өчүрүшөт, ички сайтта 403кө туш болушат жана прокси бузулду деп билдиришет. Бул баракты үч өзүнчө нерсе жаратышы мүмкүн: баштапкы булак сурамды четке какты, алдыңкы прокси туннелди ачуудан баш тартты же прокси өзүнүн эсептик маалыматтарын талап кылды. Алардын ар бири башка суроого туура жооп, ал эми аларды бир жалпы бузулуу барагына тегиздөө сиздеги жалгыз далилди жок кылат. Баш тартууну аны жараткан компонент боюнча иреттеңиз, анан ар бир компонент иш жүзүндө колдонгон тармак жолун салыштырыңыз.

403тү жараткан компонентти атаңыз

HTTP абал коду аны жөнөткөн тарапка таандык. Баштапкы булак 403 кайтарганда, ал сурамды талдап, чакыруучуда ресурс жок болушу мүмкүн деп чечкен, бул авторизация жообу, ташуу маселеси эмес. Алдыңкы прокси CONNECTке 403 деп жооп бергенде, туннелди такыр куруудан баш тартты жана жогору жакта эч ким менен байланыш болгон жок. Ал 407 деп жооп бергенде, өзүнүн эсептик маалыматтарын каалайт, алардын колдонмого кирүүгө тиешеси жок.

RFC 9110 ушул ролдорду, анын ичинде проксиге таандык чакырыкты аныктайт. Денени окуудан мурун жооптун өз статусун жана каалаган Proxy-Authenticate аталышын окуңуз, анткени достук HTML ката барагы адатта аны кайсы компонент жазганын жашырат.

CONNECT туннели байт релесинен эмнени жашырат

Прокси CONNECTке 200 кайтаргандан кийин ал байттарды өткөрүп берет жана браузер баштапкы булак менен өзүнүн 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'

Эгер бул CONNECT үчүн 200, анан TLS кол алышууну басып чыгарса, проксиге кирүү тартибинде жана кийинки 403 баштапкы булактан келди. Эгер 407 басып чыгарса, --proxy-user аркылуу проксинин эсептик маалыматтарын бериңиз жана сайт жөнүндө кандайдыр бир тыянак чыгарардан мурун кайталаңыз. Эгер CONNECT сабында 403 басып чыгарса, текшерилүүчү чек — проксинин өзүнүн уруксат тизмеси, ал эми колдонмо буга катышпайт.

Эсептик маалыматтарды shell тарыхынан жана чапталган транскрипттерден тышкары кармаңыз. Буйрук сабына терүүлөнгөн прокси сырсөзү башка жергиликтүү колдонуучуларга көрүнөт, ал эми эсептик маалыматтар менен кармалган CONNECT изи эч кандай изден жаман.

Баракты кайра жазгандын ордуна өкүмдү окулуктай кармаңыз

Кайсы компонент баш тартканын билгенден кийин ошол жоопту сактаңыз. Баштапкы булактын 403үн 504 күтүү убактысы деп кайра атаган же аны ийгилик барагы менен алмаштырган тескери прокси авторизация чечимин жеткиликтүүлүк окуясынын артына жашырат жана кийинки жооп берүүчүнү туура эмес топко жиберет. Ыңгайлаштырылган ката барактары статусту сактап, контекст кошсо жакшы.

Кэштөө да ушундай камкордукка татыктуу. RFC 9111 жалпы кэштердин жоопторду кайра колдонушу мүмкүн экенин жөнгө салат, ал эми бир чакыруучу үчүн жаралган баш тартууну экинчисине уруксат катары берүүгө болбойт. Эгер баш тартуу жооптору такыр сакталса, аларды жеке жана чектелген кармаңыз, жана жогорку агым трафигин азайтуу үчүн гана эч качан коомдук жаңылык эрежесин кошпоңуз.

Компонентти, анын жараткан статусун жана баштапкы булак көргөн булак дарегин атаган жазуу түрүндөгү өкүм менен аяктаңыз. Так сурамды, колдонуудагы прокси жөндөөлөрүн жана убакытты жазыңыз, ошондо кийинки отчет эстен кайра алынбастан, ошол эле далилдер менен салыштырыла алат. Бул жазуу кийинки отчетко секунддар ичинде жооп берет жана ошол эле 403түн кайра VPN үзүлүшү катары диагностикаланышын токтотот.