Miksi VPN-sivuston 403 ei ole välityspalvelimen vika

Käyttäjät katkaisevat VPN:n, saavat 403:n sisäisellä sivustolla ja raportoivat, että välityspalvelin on rikki. Kolme erillistä asiaa voi tuottaa tuon sivun: origin-palvelin hylkäsi pyynnön, edelleenvälittävä palvelin kieltäytyi avaamasta tunnelia tai välityspalvelin vaati omat tunnuksensa. Jokainen niistä on oikea vastaus eri kysymykseen, ja niiden litistäminen yhdeksi yleiseksi virhesivuksi tuhoaa ainoan todisteen, joka sinulla on. Lajittele hylkäys sen tuottaneen komponentin mukaan ja vertaa sitten verkkoreittiä, jota kukin komponentti todella käyttää.

Nimeä komponentti, joka tuotti 403:n

HTTP-tilakoodi kuuluu osapuolelle, joka sen lähetti. Kun origin palauttaa 403:n, se on jäsentänyt pyynnön ja päättänyt, että kutsujalla ei ehkä ole resurssia, mikä on valtuutusvastaus eikä siirto-ongelma. Kun edelleenvälittävä palvelin vastaa 403:lla CONNECTiin, se kieltäytyi rakentamasta tunnelia lainkaan, eikä ylävirrassa otettu koskaan yhteyttä mihinkään. Kun se vastaa 407:llä, se haluaa omat tunnuksensa, joilla ei ole mitään tekemistä sovelluksen kirjautumisen kanssa.

RFC 9110 määrittelee nämä roolit, mukaan lukien välityspalvelinkohtaisen haasteen. Lue vastauksen oma tila ja mahdollinen Proxy-Authenticate-otsake ennen runkoa, koska ystävällinen HTML-virhesivu yleensä kätkee, mikä komponentti sen kirjoitti.

Mitä CONNECT-tunneli kätkee tavuvälittäjältä

Kun välityspalvelin palauttaa 200:n CONNECTille, se välittää tavuja ja selain pitää oman TLS-istuntonsa originin kanssa. Tavuja välittävä palvelin ei siksi voi lukea salattua 403:a tuon istunnon sisällä, eikä siitä koskaan tule hylkäyksen kirjoittajaa. Kieltäytyminen ennen tunnelin avautumista on täysin eri tapahtuma, joka syntyy yhtä kerrosta alempana.

TLS:n päättävä käänteinen välityspalvelin on eri asemassa: se omistaa TLS-rajan, jäsentää HTTP:tä ja voi laillisesti kirjoittaa vastauksia uudelleen tai siepata niitä. Se kyky on kokoonpanovalinta, ei välityksen yleinen ominaisuus, eikä se oikeuta ohittamaan sovelluksen käyttöoikeuskäytäntöä. Vastauksen lukeminen on kyky; päättäminen siitä, mitä kutsuja saa nähdä, jää originin tehtäväksi.

Käytännön seuraus on, että sinun on tiedettävä, mitä kolmesta muodosta ajat, ennen kuin tulkitset 403:n. HTTP-tarkastussääntöjen lisääminen virranvälityspalvelimelle ei anna sille näkyvyyttä, ja tavuvälittäjän odottaminen selittävän originin hylkäyksen lähettää sinut väärään lokiin.

Vertaa välityspalvelimen lähtöreittiä selaimen tunneliosoitteeseen

VPN:ään kytketty selain ei automaattisesti siirrä erillistä välityspalvelinta tuohon tunneliin. Origin näkee välityspalvelimen lähtöosoitteen, ja jos välityspalvelin poistuu yhä paikallisen oletusreitin kautta, suojattu sivusto näkee osoitteen, jota sen ei koskaan määritetty luottamaan. Kannettavan sisäinen VPN-osoite on näkymätön tuolle originille. Tämä on yleisin syy siihen, että toimiva tunneli antaa yhä 403:n sivustolta, joka käyttäytyy oikein kaikkia muita kohtaan.

Testaa kaksi reittiä erikseen, jotta osoitteet eivät sekoitu.

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

Ensimmäinen pyyntö näyttää, mitä origin vastaa omalle osoitteellesi, toinen näyttää, mitä se vastaa välityspalvelimen osoitteelle. Täsmäävä 403-pari viittaa originin valtuutussääntöihin; 200, jota seuraa 403, viittaa välityspalvelimen reittiin. Kysy originin omistajalta, mitkä lähdeosoitteet sääntöjoukko todella hyväksyy, sen sijaan että olettaisit VPN-poolin olevan mukana.

Testaa jokaista rajaa pyynnöllä, joka eristää sen

Eristä välityspalvelinkerros pyytämällä siltä jotain, mitä se ei voi sovellussyistä evätä. CONNECT isäntään, johon välityspalvelin saa päästä, tuloste hylättynä, kertoo, toimiiko tunnelin hyväksyntä lainkaan.

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'

Jos se tulostaa 200:n CONNECTille ja sitten TLS-kättelyn, välityspalvelimen hyväksyntä on kunnossa ja myöhempi 403 tuli originilta. Jos se tulostaa 407:n, anna välityspalvelimen tunnukset --proxy-user-asetuksella ja toista ennen kuin teet mitään johtopäätöstä sivustosta. Jos se tulostaa 403:n CONNECT-rivillä, välityspalvelimen oma sallittujen luettelo on tutkittava raja, eikä sovellus ole mukana.

Pidä tunnukset poissa komentotulkin historiasta ja liitetyistä litteroinneista. Komentoriville kirjoitettu välityspalvelimen salasana näkyy muille paikallisille käyttäjille, ja tunnuksineen tallennettu CONNECT-jälki on huonompi kuin ei jälkeä lainkaan.

Pidä päätös luettavana sen sijaan että kirjoittaisit sivun uudelleen

Kun tiedät, mikä komponentti kieltäytyi, säilytä tuo vastaus. Käänteinen välityspalvelin, joka nimeää originin 403:n uudelleen 504-aikakatkoksi tai korvaa sen onnistumissivulla, kätkee valtuutuspäätöksen saatavuustarinan taakse ja lähettää seuraavan vastaajan väärään tiimiin. Mukautetut virhesivut ovat hyviä, kun ne säilyttävät tilan ja lisäävät kontekstia.

Välimuisti ansaitsee saman huolen. RFC 9111 säätelee, miten jaetut välimuistit voivat käyttää vastauksia uudelleen, eikä yhdelle kutsujalle tuotettua hylkäystä saa antaa toiselle ikään kuin se olisi lupa. Jos hylkäysvastauksia ylipäätään tallennetaan, pidä ne yksityisinä ja rajattuina, äläkä koskaan lisää julkista tuoreussääntöä vain ylävirran liikenteen vähentämiseksi.

Lopeta kirjalliseen päätökseen, joka nimeää komponentin, sen tuottaman tilan ja lähdeosoitteen, jonka origin näki. Kirjaa tarkka pyyntö, voimassa olevat välityspalvelinasetukset ja aika, jotta seuraava raportti voidaan sovittaa samoihin todisteisiin sen sijaan että se johdettaisiin uudelleen muistista. Se kirjaus vastaa seuraavaan raporttiin sekunneissa ja estää saman 403:n diagnosoimisen uudelleen VPN-katkokseksi.