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 тасалдал гэж оношлохоос сэргийлнэ.