VPN сайтынан келген 403 неге прокси ақауы емес
Бастапқы көзден 403, қабылданбаған CONNECT және 407 шақыруы әртүрлі шекараларды белгілейді. Алдымен проксидің шығу жолын браузердің VPN мекенжайымен салыстырыңыз.
Пайдаланушылар VPN-ды өшіреді, ішкі сайтта 403-ке тап болады және прокси бұзылған деп хабарлайды. Бұл бетті үш бөлек нәрсе жасай алады: бастапқы көз сұраныстан бас тартты, алдыңғы прокси туннельді ашудан бас тартты немесе прокси өзінің тіркелгі деректерін талап етті. Олардың әрқайсысы басқа сұраққа дұрыс жауап, ал оларды бір жалпы ақау бетіне тегістеу сіздегі жалғыз дәлелді жояды. Бас тартуды оны жасаған компонент бойынша реттеңіз, содан кейін әр компонент іс жүзінде пайдаланатын желілік жолды салыстырыңыз.
403-ті жасаған компонентті атаңыз
HTTP күй коды оны жіберген тарапқа тиесілі. Бастапқы көз 403 қайтарғанда, ол сұранысты талдап, шақырушыда ресурс болмауы мүмкін деп шешті, бұл авторизация жауабы, тасымал мәселесі емес. Алдыңғы прокси CONNECT-ке 403 деп жауап бергенде, туннельді мүлде салудан бас тартты және жоғары жақта ешкіммен байланыс орнатылған жоқ. Ол 407 деп жауап бергенде, өзінің тіркелгі деректерін қалайды, олардың қолданбаға кіруге қатысы жоқ.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
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 үзілісі ретінде диагностикалануын тоқтатады.