Nega VPN saytidan kelgan 403 proksi nosozligi emas

Foydalanuvchilar VPNni o‘chiradi, ichki saytda 403 ga duch keladi va proksi buzilgan deb xabar beradi. Bu sahifani uch xil narsa yaratishi mumkin: manba so‘rovni rad etdi, yo‘naltiruvchi proksi tunnelni ochishdan bosh tortdi yoki proksi o‘z hisob ma’lumotlarini talab qildi. Ularning har biri boshqa savolga to‘g‘ri javob, va ularni bitta umumiy nosozlik sahifasiga tekislash sizdagi yagona dalilni yo‘q qiladi. Rad etishni uni yaratgan komponent bo‘yicha ajrating, so‘ngra har bir komponent amalda ishlatadigan tarmoq yo‘lini solishtiring.

403 ni yaratgan komponentni nomlang

HTTP holat kodi uni yuborgan tomonga tegishli. Manba 403 qaytarganda, u so‘rovni tahlil qilgan va chaqiruvchida resurs bo‘lmasligi mumkin deb qaror qilgan, bu avtorizatsiya javobi, transport muammosi emas. Yo‘naltiruvchi proksi CONNECT ga 403 deb javob berganda, u tunnelni umuman qurishdan bosh tortgan va yuqorida hech kim bilan aloqa o‘rnatilmagan. U 407 deb javob berganda, o‘z hisob ma’lumotlarini xohlaydi, ularning ilovaga kirishga aloqasi yo‘q.

RFC 9110 bu rollarni, shu jumladan proksiga xos sinovni belgilaydi. Tanani o‘qishdan oldin javobning o‘z holatini va har qanday Proxy-Authenticate sarlavhasini o‘qing, chunki do‘stona HTML xato sahifasi odatda uni qaysi komponent yozganini yashiradi.

CONNECT tunneli bayt uzatishdan nimani yashiradi

Proksi CONNECT ga 200 qaytargach, u baytlarni uzatadi va brauzer manba bilan o‘z TLS sessiyasini saqlaydi. Shuning uchun baytlarni uzatuvchi proksi o‘sha sessiya ichidagi shifrlangan 403 ni o‘qiy olmaydi va hech qachon rad etish muallifi bo‘lmaydi. Tunnel ochilishidan oldingi rad etish butunlay boshqa hodisa bo‘lib, bir qatlam pastda yaratiladi.

TLS ni tugatuvchi teskari proksi boshqa holatda: u TLS chegarasiga ega, HTTP ni tahlil qiladi va javoblarni qonuniy ravishda qayta yozishi yoki ushlab qolishi mumkin. Bu qobiliyat konfiguratsiya tanlovi, umuman proksining xossasi emas va ilovaning kirish siyosatini chetlab o‘tishga huquq bermaydi. Javobni o‘qish qobiliyat; chaqiruvchi nima ko‘rishi mumkinligini hal qilish manbaning ishi bo‘lib qoladi.

Amaliy natija shuki, 403 ni talqin qilishdan oldin uch shakldan qaysi birini ishlatayotganingizni bilishingiz kerak. Oqim proksisiga HTTP tekshiruv qoidalarini qo‘shish unga ko‘rinish bermaydi, va bayt uzatishdan manba rad etishini tushuntirishni kutish sizni noto‘g‘ri jurnalga yuboradi.

Proksining chiqish yo‘lini brauzerning tunnel manzili bilan solishtiring

VPN ga ulangan brauzer alohida proksi serverni avtomatik ravishda o‘sha tunnelga ko‘chirmaydi. Manba proksining chiqish manzilini ko‘radi, va agar proksi hali ham mahalliy standart marshrut orqali chiqsa, himoyalangan sayt hech qachon ishonish uchun sozlanmagan manzilni ko‘radi. Noutbukdagi ichki VPN manzili o‘sha manba uchun ko‘rinmas. Ishlayotgan tunnel ham boshqalarga to‘g‘ri munosabatda bo‘lgan saytdan 403 berishining eng keng tarqalgan sababi shu.

Manzillar chalkashmasligi uchun ikkala yo‘lni alohida sinab ko‘ring.

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

Birinchi so‘rov manba sizning manzilingizga nima deb javob berishini, ikkinchisi proksi manziliga nima deb javob berishini ko‘rsatadi. Mos keladigan 403 juftligi manbaning avtorizatsiya qoidalariga ishora qiladi; 200 dan keyin kelgan 403 proksi yo‘liga ishora qiladi. VPN hovuzi kiritilgan deb taxmin qilish o‘rniga manba egasidan qoidalar to‘plami qaysi manba manzillarini haqiqatda qabul qilishini so‘rang.

Har bir chegarani uni izolyatsiya qiluvchi so‘rov bilan sinang

Proksi qatlamini ilova sabablari bilan rad eta olmaydigan narsani so‘rash orqali ajratib oling. Proksiga yetishga ruxsat berilgan xostga CONNECT, chiqish tashlab yuborilgan holda, tunnelga kirish umuman ishlaydimi-yo‘qmi aytadi.

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'

Agar bu CONNECT uchun 200 va keyin TLS qo‘l berishini chiqarsa, proksi kirishi joyida va keyingi 403 manbadan kelgan. Agar 407 chiqarsa, --proxy-user bilan proksi hisob ma’lumotlarini bering va sayt haqida har qanday xulosa qilishdan oldin takrorlang. Agar CONNECT satrida 403 chiqarsa, tekshiriladigan chegara proksining o‘z ruxsat ro‘yxati, va ilova bu ishga aralashmaydi.

Hisob ma’lumotlarini shell tarixidan va yopishtirilgan nusxalardan uzoq tuting. Buyruq satrida terilgan proksi paroli boshqa mahalliy foydalanuvchilarga ko‘rinadi, va hisob ma’lumotlari bilan ushlangan CONNECT izi hech qanday izdan yomonroq.

Sahifani qayta yozish o‘rniga hukmni o‘qish mumkin holda saqlang

Qaysi komponent rad etganini bilganingizdan keyin o‘sha javobni saqlang. Manbaning 403 ini 504 vaqt tugashi deb qayta belgilovchi yoki uni muvaffaqiyat sahifasi bilan almashtiruvchi teskari proksi avtorizatsiya qarorini mavjudlik hikoyasi orqasiga yashiradi va keyingi javob beruvchini noto‘g‘ri jamoaga yuboradi. Moslashtirilgan xato sahifalari holatni saqlab, kontekst qo‘shganda yaxshi.

Keshlash ham xuddi shunday e’tiborga loyiq. RFC 9111 umumiy keshlar javoblarni qanday qayta ishlatishi mumkinligini tartibga soladi, va bir chaqiruvchi uchun yaratilgan rad etish boshqasiga ruxsat kabi berilmasligi kerak. Rad etish javoblari baribir saqlansa, ularni shaxsiy va cheklangan holda saqlang, va faqat yuqori oqim trafigini kamaytirish uchun hech qachon ommaviy yangilik qoidasini qo‘shmang.

Komponent, uning yaratgan holati va manba ko‘rgan manba manzilini nomlaydigan yozma hukm bilan yakunlang. Aniq so‘rovni, amaldagi proksi sozlamalarini va vaqtni qayd eting, shunda keyingi hisobot xotiradan qayta olinmasdan o‘sha dalillar bilan solishtirilishi mumkin. Bu yozuv keyingi hisobotga soniyalar ichida javob beradi va o‘sha 403 ning yana VPN uzilishi sifatida aniqlanishini to‘xtatadi.