Miks VPN-saidi 403 ei ole puhverserveri rike
Päritolu 403, keeldutud CONNECT ja 407 väljakutse tähistavad erinevaid piire. Kõigepealt võrrelge puhverserveri väljumisteed brauseri VPN-aadressiga.
Kasutajad lahutavad VPN-i, saavad sisemisel saidil 403 ja teatavad, et puhverserver on katki. Seda lehte võivad tekitada kolm eraldi asja: päritolu keeldus päringust, edasivoolav puhverserver keeldus tunnelit avamast või nõudis puhverserver oma mandaate. Igaüks neist on õige vastus erinevale küsimusele, ja nende lömamine üheks üldiseks vealeheks hävitab ainsa tõendi, mis teil on. Sorteerige keeldumine komponendi järgi, mis selle tekitas, ja võrrelge seejärel võrguteed, mida iga komponent tegelikult kasutab.
Nimetage komponent, mis 403 tekitas
HTTP olekukood kuulub osapoolele, kes selle saatis. Kui päritolu tagastab 403, on see päringu jäsendanud ja otsustanud, et kutsuja ei pruugi ressurssi omada, mis on autoriseerimisvastus, mitte transpordiprobleem. Kui edasivoolav puhverserver vastab CONNECT-le 403-ga, keeldus ta tunnelit üldse ehitamast ja ülesvoolu ei võetud kunagi kellegagi ühendust. Kui ta vastab 407-ga, tahab ta oma mandaate, millel pole rakenduse sisselogimisega mingit pistmist.
| 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 määratleb need rollid, sealhulgas puhverserveripõhise väljakutse. Lugege vastuse enda olekut ja mis tahes Proxy-Authenticate-päist enne keha lugemist, sest sõbralik HTML-vigaleht varjab tavaliselt, milline komponent selle kirjutas.
Mida CONNECT-tunnel baitvahendajalt varjab
Kui puhverserver tagastab CONNECT-le 200, edastab ta baite ja brauser hoiab päritoluga oma TLS-seanssi. Baitte edastav puhverserver ei saa seega selle seansi sees olevat krüpteeritud 403 lugeda ja temast ei saa kunagi keeldumise autorit. Keeldumine enne tunneli avanemist on hoopis teine sündmus, mis tekib ühe kihi võrra allpool.
TLS-i lõpetav vastupuhverserver on teises positsioonis: ta omab TLS-piiri, jäsendab HTTP-d ja võib õiguspäraselt vastuseid ümber kirjutada või vahelt võtta. See võime on konfiguratsioonivalik, mitte puhverserveri üldine omadus, ja see ei anna õigust rakenduse juurdepääsupoliitikast mööda minna. Vastuse lugemine on võime; otsustamine, mida kutsuja tohib näha, jääb päritolu ülesandeks.
Praktiline tagajärg on see, et peate teadma, millist kolmest vormist käitate, enne kui 403-t tõlgendate. HTTP-inspektsiooni reeglite lisamine voopuhverserverile ei anna sellele nähtavust, ja baitvahendajalt päritolu keeldumise selgitamise ootamine saadab teid valesse logisse.
Võrrelge puhverserveri väljumisteed brauseri tunneli aadressiga
VPN-iga ühendatud brauser ei vii eraldi puhverserverit automaatselt sellele tunnelile. Päritolu näeb puhverserveri väljumisaadressi, ja kui puhverserver väljub endiselt kohaliku vaikimisi marsruudi kaudu, näeb kaitstud sait aadressi, millele ei olnud kunagi usaldamist seadistatud. Sülearvuti sisemine VPN-aadress on sellele päritolule nähtamatu. See on kõige tavalisem põhjus, miks töötav tunnel annab endiselt 403 saidilt, mis käitub kõigi teiste suhtes korrektselt.
Testige kahte teed eraldi, et aadresse ei saaks segi ajada.
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/privateEsimene päring näitab, mida päritolu vastab teie enda aadressile, teine näitab, mida ta vastab puhverserveri aadressile. Sobiv 403 paar osutab päritolu autoriseerimisreeglitele; 200, millele järgneb 403, osutab puhverserveri teele. Küsige päritolu omanikult, milliseid lähteaadresse reeglistik tegelikult lubab, selle asemel et eeldada, et VPN-i pool on kaasatud.
Testige iga piiri päringuga, mis selle isoleerib
Isoleerige puhverserveri kiht, paludes sellelt midagi, millest ta ei saa rakendusepõhjustel keelduda. CONNECT hostile, kuhu puhverserver tohib jõuda, väljund kõrvale jäetud, ütleb teile, kas tunnelisse lubamine üldse töötab.
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'
Kui see prindib CONNECT-i jaoks 200 ja seejärel TLS-i kätluse, on puhverserveri lubamine korras ja hilisem 403 tuli päritolult. Kui see prindib 407, esitage puhverserveri mandaadid --proxy-user abil ja korrake enne, kui teete saidi kohta mis tahes järelduse. Kui see prindib CONNECT-i real 403, on uuritav piir puhverserveri enda lubatud nimekiri ja rakendus ei ole sellesse kaasatud.
Hoidke mandaadid kestahistorioast ja kleepitud transkriptidest eemal. Käsureale trükitud puhverserveri parool on nähtav teistele kohalikele kasutajatele ja mandaatidega jäädvustatud CONNECT-jälg on hullem kui üldse jälg.
Hoidke otsus loetav, selle asemel et lehte ümber kirjutada
Kui teate, milline komponent keeldus, säilitage see vastus. Vastupuhverserver, mis nimetab päritolu 403 ümber 504-ks ajalõpuks või asendab selle õnnestumislehega, peidab autoriseerimisotsuse kättesaadavusloo taha ja saadab järgmise vastaja valesse meeskonda. Kohandatud vealehed on head, kui need säilitavad oleku ja lisavad konteksti.
Vahemällu salvestamine väärib sama hoolt. RFC 9111 reguleerib, kuidas jagatud vahemälud tohivad vastuseid uuesti kasutada, ja ühele kutsujale loodud keeldumist ei tohi anda teisele nii, nagu oleks see luba. Kui keeldumisvastuseid üldse salvestatakse, hoidke need privaatsed ja piiratud, ja ärge kunagi lisage avalikku värskusreeglit ainult ülesvoolu liikluse vähendamiseks.
Lõpetage kirjaliku otsusega, mis nimetab komponendi, selle tekitatud oleku ja lähteaadressi, mida päritolu nägi. Registreerige täpne päring, kehtivad puhverserveri seaded ja aeg, et järgmist aruannet saaks samade tõenditega kõrvutada, mitte mälust uuesti tuletada. See kanne vastab järgmisele aruandele sekunditega ja hoiab ära sama 403 uuesti diagnoosimise VPN-i katkestusena.