Kial 403 de VPN-ejo ne estas prokura fiasko

Uzantoj malkonektas la VPN, trafas 403 ĉe interna ejo kaj raportas, ke la prokuro estas difektita. Tri apartaj aferoj povas produkti tiun paĝon: la origino rifuzis la peton, la antaŭa prokuro rifuzis malfermi la tunelon, aŭ la prokuro postulis proprajn akreditaĵojn. Ĉiu el ili estas ĝusta respondo al malsama demando, kaj platigi ilin en unu ĝeneralan fiaskan paĝon detruas la solan pruvon, kiun vi havas. Ordigu la rifuzon laŭ la komponanto, kiu faris ĝin, poste komparu la retan vojon, kiun ĉiu komponanto efektive uzas.

Nomu la komponanton, kiu produktis la 403

HTTP-statokodo apartenas al la partio, kiu sendis ĝin. Kiam la origino redonas 403, ĝi analizis la peton kaj decidis, ke la alvokanto eble ne havas la rimedon, kio estas respondo pri rajtigo, ne transporta problemo. Kiam antaŭa prokuro respondas 403 al CONNECT, ĝi rifuzis entute konstrui la tunelon, kaj nenio supre estis iam kontaktita. Kiam ĝi respondas 407, ĝi volas proprajn akreditaĵojn, kiuj havas nenion komunan kun la ensaluto de la aplikaĵo.

RFC 9110 difinas tiujn rolojn, inkluzive de la prokura defio. Legu la propran staton de la respondo kaj ajnan Proxy-Authenticate-kapon antaŭ ol legi la korpon, ĉar amika HTML-erarpaĝo kutime kaŝas, kiu komponanto skribis ĝin.

Kion CONNECT-tunelo kaŝas de bajta relajso

Post kiam prokuro redonas 200 al CONNECT, ĝi relajsas bajtojn kaj la retumilo konservas sian propran TLS-sesion kun la origino. Bajtrelajsa prokuro do ne povas legi la ĉifritan 403 ene de tiu sesio, kaj ĝi neniam fariĝas la aŭtoro de la rifuzo. Rifuzo antaŭ ol la tunelo malfermiĝas estas tute alia okazaĵo, produktita unu tavolon pli malalte.

TLS-finanta inversa prokuro staras en alia pozicio: ĝi posedas la TLS-limon, analizas HTTP kaj povas laŭleĝe reskribi aŭ interkapti respondojn. Tiu kapablo estas agorda elekto, ne eco de prokurado ĝenerale, kaj ĝi ne rajtigas ĉirkaŭiri la alirpolitikon de la aplikaĵo. Legi la respondon estas kapablo; decidi, kion la alvokanto rajtas vidi, restas la tasko de la origino.

La praktika sekvo estas, ke vi devas scii, kiun el la tri formoj vi funkciigas, antaŭ ol interpreti 403. Aldoni HTTP-inspektajn regulojn al fluprokuro ne donas al ĝi videblecon, kaj atendi, ke bajtrelajso klarigu originan rifuzon, sendos vin serĉi en la malĝusta protokolo.

Komparu la eliran vojon de la prokuro kun la tunela adreso de la retumilo

Retumilo konektita al VPN ne aŭtomate movas apartan prokuran servilon sur tiun tunelon. La origino vidas la eliran adreson de la prokuro, kaj se la prokuro ankoraŭ eliras tra la loka defaŭlta vojo, la protektita ejo vidas adreson, kiun ĝi neniam estis agordita fidi. La interna VPN-adreso sur la tekokomputilo estas nevidebla al tiu origino. Tio estas la plej ofta kialo, kial funkcianta tunelo ankoraŭ donas 403 de ejo, kiu kondutas ĝuste por ĉiuj aliaj.

Testu la du vojojn aparte, por ke la adresoj ne konfuziĝu.

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

La unua peto montras, kion la origino respondas al via propra adreso, la dua montras, kion ĝi respondas al tiu de la prokuro. Kongrua paro da 403 indikas la rajtigajn regulojn de la origino; 200 sekvata de 403 indikas la prokuran vojon. Demandu la posedanton de la origino, kiujn fontadresojn la regularo efektive akceptas, anstataŭ supozi, ke la VPN-pulo estas inkluzivita.

Testu ĉiun limon per peto, kiu izolas ĝin

Izolu la prokuran tavolon petante de ĝi ion, kion ĝi ne povas rifuzi pro aplikaĵaj kialoj. CONNECT al gastiganto, kiun la prokuro rajtas atingi, kun forĵetita eligo, diras al vi, ĉu tunela akcepto entute funkcias.

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'

Se tio presas 200 por la CONNECT kaj poste TLS-manpremon, la prokura akcepto estas en ordo kaj la posta 403 venis de la origino. Se ĝi presas 407, provizu prokurajn akreditaĵojn per --proxy-user kaj ripetu antaŭ ol tiri ajnan konkludon pri la ejo. Se ĝi presas 403 sur la CONNECT-linio, la propra permeslisto de la prokuro estas la limo por ekzameni, kaj la aplikaĵo ne estas implikita.

Tenu akreditaĵojn ekster la ŝela historio kaj ekster algluitaj transskriboj. Prokura pasvorto tajpita en komandlinio estas videbla al aliaj lokaj uzantoj, kaj kaptita CONNECT-spuro kun akreditaĵoj estas pli malbona ol neniu spuro.

Tenu la verdikton legebla anstataŭ reskribi la paĝon

Post kiam vi scias, kiu komponanto rifuzis, konservu tiun respondon. Inversa prokuro, kiu renomas originan 403 kiel 504-tempon, aŭ anstataŭigas ĝin per sukcesa paĝo, kaŝas rajtigan decidon malantaŭ havebla rakonto kaj sendas la sekvan respondanton al la malĝusta teamo. Propraj erarpaĝoj estas bonaj, kiam ili konservas la statuson kaj aldonas kuntekston.

Kaŝmemorigo meritas la saman zorgon. RFC 9111 regas, kiel komunaj kaŝmemoroj rajtas reuzi respondojn, kaj rifuzo produktita por unu alvokanto ne rajtas esti transdonita al alia kvazaŭ ĝi estus permeso. Se rifuzaj respondoj entute estas konservataj, tenu ilin privataj kaj limigitaj, kaj neniam aldonu publikan freŝec-regulon nur por malpliigi suprenan trafikon.

Finu per skribita verdikto, kiu nomas la komponanton, la statuson, kiun ĝi produktis, kaj la fontadreson, kiun la origino vidis. Registru la precizan peton, la validajn prokurajn agordojn kaj la tempon, por ke la sekva raporto povu esti komparita kun la samaj pruvoj anstataŭ re-derivita el memoro. Tiu registro respondas la sekvan raporton en sekundoj kaj malhelpas, ke la sama 403 estu diagnozita denove kiel VPN-paneo.