Bakit ang 403 mula sa isang VPN site ay hindi kabiguan ng proxy

Niwawaksi ng mga gumagamit ang VPN, nakakatagpo ng 403 sa isang panloob na site at iniuulat na sira ang proxy. Tatlong magkaibang bagay ang makakagawa ng pahinang iyon: tinanggihan ng pinagmulan ang kahilingan, tumanggi ang pasulong na proxy na buksan ang tunel, o humingi ang proxy ng sarili nitong mga kredensyal. Ang bawat isa ay tamang sagot sa magkaibang tanong, at ang pagpapatag sa kanila sa isang pangkalahatang pahina ng kabiguan ay sumisira sa tanging ebidensya na mayroon ka. Ayusin ang pagtanggi ayon sa bahaging gumawa nito, pagkatapos ay ihambing ang daanan ng network na aktwal na ginagamit ng bawat bahagi.

Pangalanan ang bahaging gumawa ng 403

Ang HTTP status code ay pag-aari ng partidong nagpadala nito. Kapag nagbalik ang pinagmulan ng 403, sinuri nito ang kahilingan at nagpasya na maaaring wala ang mapagkukunan sa tumatawag, na sagot tungkol sa awtorisasyon at hindi problema sa transportasyon. Kapag sumagot ang pasulong na proxy ng 403 sa CONNECT, tumanggi itong itayo ang tunel nang buo, at wala sa itaas ang naabot. Kapag sumagot ito ng 407, gusto nito ang sarili nitong mga kredensyal, na walang kaugnayan sa pag-login ng aplikasyon.

Tinutukoy ng RFC 9110 ang mga papel na ito, kasama ang hamong partikular sa proxy. Basahin ang sariling status ng tugon at anumang Proxy-Authenticate header bago basahin ang katawan, dahil ang magiliw na HTML error page ay karaniwang nagtatago kung aling bahagi ang sumulat nito.

Ano ang itinatago ng CONNECT tunnel sa isang byte relay

Kapag nagbalik ang proxy ng 200 sa CONNECT, nagpapasa ito ng mga byte at pinapanatili ng browser ang sarili nitong TLS session sa pinagmulan. Kaya hindi mabasa ng proxy na nagpapasa ng byte ang naka-encrypt na 403 sa loob ng session na iyon, at hindi ito kailanman nagiging may-akda ng pagtanggi. Ang pagtanggi bago bumukas ang tunel ay ganap na ibang pangyayari, na ginawa isang patong sa ibaba.

Ang reverse proxy na nagtatapos ng TLS ay nasa ibang posisyon: pag-aari nito ang hangganan ng TLS, sinusuri nito ang HTTP at lehitimong maaari nitong isulat muli o harangin ang mga tugon. Ang kakayahang iyon ay pagpipilian sa configuration, hindi katangian ng proxy sa pangkalahatan, at hindi ito nagbibigay ng awtoridad na laktawan ang patakaran sa pag-access ng aplikasyon. Ang pagbasa ng tugon ay kakayahan; ang pagpapasya kung ano ang makikita ng tumatawag ay nananatiling trabaho ng pinagmulan.

Ang praktikal na bunga ay kailangan mong malaman kung alin sa tatlong anyo ang pinapatakbo mo bago bigyang-kahulugan ang 403. Ang pagdaragdag ng mga patakaran sa HTTP inspection sa isang stream proxy ay hindi nagbibigay dito ng visibility, at ang pag-asa na ipapaliwanag ng byte relay ang pagtanggi ng pinagmulan ay magpapadala sa iyo sa maling log.

Ihambing ang daanan ng labasan ng proxy sa address ng tunel ng browser

Ang browser na konektado sa VPN ay hindi awtomatikong naglilipat ng hiwalay na proxy server papunta sa tunel na iyon. Nakikita ng pinagmulan ang address ng labasan ng proxy, at kung lumalabas pa rin ang proxy sa lokal na default na ruta, nakikita ng protektadong site ang address na kailanman ay hindi na-configure upang pagkatiwalaan. Ang panloob na VPN address sa laptop ay hindi nakikita ng pinagmulang iyon. Ito ang pinakakaraniwang dahilan kung bakit ang gumaganang tunel ay nagbibigay pa rin ng 403 mula sa site na kumikilos nang tama sa lahat ng iba.

Subukan ang dalawang daanan nang hiwalay upang hindi magkamalang ang mga address.

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

Ipinapakita ng unang kahilingan kung ano ang isinasagot ng pinagmulan sa sarili mong address, ipinapakita ng pangalawa kung ano ang isinasagot nito sa address ng proxy. Ang magkatugmang pares ng 403 ay tumuturo sa mga patakaran sa awtorisasyon ng pinagmulan; ang 200 na sinusundan ng 403 ay tumuturo sa daanan ng proxy. Tanungin ang may-ari ng pinagmulan kung aling mga source address ang aktwal na tinatanggap ng hanay ng patakaran sa halip na ipagpalagay na kasama ang VPN pool.

Subukan ang bawat hangganan sa isang kahilingang naghihiwalay dito

Ihiwalay ang patong ng proxy sa pamamagitan ng paghingi dito ng isang bagay na hindi nito matatanggihan dahil sa mga dahilan ng aplikasyon. Ang CONNECT sa isang host na pinapayagang abutin ng proxy, na itinapon ang output, ay magsasabi sa iyo kung gumagana man lang ang pagtanggap sa tunel.

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'

Kung nagpi-print ito ng 200 para sa CONNECT at pagkatapos ay isang TLS handshake, maayos ang pagtanggap ng proxy at ang 403 na sumunod ay nagmula sa pinagmulan. Kung nagpi-print ito ng 407, magbigay ng kredensyal ng proxy gamit ang --proxy-user at ulitin bago gumawa ng anumang konklusyon tungkol sa site. Kung nagpi-print ito ng 403 sa linyang CONNECT, ang sariling allow-list ng proxy ang hangganang dapat suriin, at hindi kasangkot ang aplikasyon.

Ilayo ang mga kredensyal sa kasaysayan ng shell at sa mga na-paste na transcript. Ang password ng proxy na nai-type sa command line ay nakikita ng iba pang lokal na gumagamit, at ang nakuhang CONNECT trace na may kredensyal ay mas masahol pa sa walang trace.

Panatilihing nababasa ang hatol sa halip na isulat muli ang pahina

Kapag alam mo kung aling bahagi ang tumanggi, pangalagaan ang sagot na iyon. Ang reverse proxy na nagpapalit ng pangalan sa 403 ng pinagmulan bilang timeout 504, o pinapalitan ito ng pahina ng tagumpay, ay nagtatago ng desisyon sa awtorisasyon sa likod ng kuwento ng availability at nagpapadala sa susunod na tutugon sa maling koponan. Ang mga custom na error page ay maayos kapag pinapanatili nila ang status at nagdadagdag ng konteksto.

Ang caching ay nararapat sa parehong pag-iingat. Ang RFC 9111 ay nagreregula kung paano maaaring muling gamitin ng mga shared cache ang mga tugon, at ang pagtangging ginawa para sa isang tumatawag ay hindi dapat ibigay sa iba na parang pahintulot. Kung ang mga tugon ng pagtanggi ay iniimbak man, panatilihin silang pribado at limitado, at huwag kailanman magdagdag ng pampublikong panuntunan sa freshness para lang bawasan ang trapiko sa itaas.

Tapusin sa isang nakasulat na hatol na nagpangalan sa bahagi, sa status na ginawa nito at sa source address na nakita ng pinagmulan. Itala ang eksaktong kahilingan, ang mga setting ng proxy na may bisa at ang oras, upang ang susunod na ulat ay maihambing sa parehong ebidensya sa halip na muling makuha mula sa memorya. Ang talaang iyon ay sumasagot sa susunod na ulat sa loob ng ilang segundo at pumipigil sa parehong 403 na muling masuri bilang pagkaantala ng VPN.