Miért nem proxyhiba egy VPN-oldal 403-as válasza
Az eredeti 403, az elutasított CONNECT és a 407 kihívás különböző határokat jelöl. Először hasonlítsa össze a proxy kimeneti útvonalát a böngésző VPN-címével.
A felhasználók lecsatlakoztatják a VPN-t, 403-at kapnak egy belső oldalon, és jelentik, hogy a proxy elromlott. Három külön dolog hozhatja létre ezt az oldalt: az eredeti elutasította a kérést, az előremenő proxy megtagadta az alagút megnyitását, vagy a proxy a saját hitelesítő adatait kérte. Mindegyik más kérdésre adott helyes válasz, és egyetlen általános hibaoldallá laposításuk megsemmisíti az egyetlen bizonyítékot, amivel rendelkezik. Rendezze az elutasítást az azt létrehozó komponens szerint, majd hasonlítsa össze az egyes komponensek által ténylegesen használt hálózati útvonalat.
Nevezze meg a 403-at létrehozó komponenst
Az HTTP-állapotkódot küldő félhez tartozik. Amikor az eredeti 403-at ad vissza, feldolgozta a kérést, és úgy döntött, hogy a hívó esetleg nem rendelkezik az erőforrással, ami engedélyezési válasz, nem pedig átviteli probléma. Amikor egy előremenő proxy 403-at válaszol egy CONNECT-re, egyáltalán megtagadta az alagút építését, és semmit nem értek el a felsőbb szinteken. Amikor 407-et válaszol, a saját hitelesítő adatait kéri, amelyeknek semmi közük az alkalmazás bejelentkezéséhez.
| 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 |
Az RFC 9110 meghatározza ezeket a szerepeket, beleértve a proxyra jellemző kihívást. A törzs olvasása előtt olvassa el a válasz saját állapotát és bármely Proxy-Authenticate fejlécet, mert egy barátságos HTML-hibaoldal általában elrejti, melyik komponens írta.
Mit rejt el egy CONNECT-alagút egy bájtrelé elől
Miután a proxy 200-at ad vissza a CONNECT-re, bájtokat továbbít, és a böngésző a saját TLS-munkamenetét tartja fenn az eredetivel. Egy bájtokat továbbító proxy ezért nem tudja elolvasni a titkosított 403-at ezen a munkameneten belül, és soha nem válik az elutasítás szerzőjévé. Az alagút megnyitása előtti elutasítás teljesen más esemény, egy szinttel lejjebb keletkezik.
A TLS-t lezáró fordított proxy más helyzetben van: övé a TLS-határ, elemzi a HTTP-t, és jogosan írhatja át vagy foghatja el a válaszokat. Ez a képesség konfigurációs döntés, nem a proxy általános tulajdonsága, és nem jogosít fel az alkalmazás hozzáférési szabályzatának megkerülésére. A válasz olvasása képesség; annak eldöntése, hogy a hívó mit láthat, továbbra is az eredeti feladata.
A gyakorlati következmény az, hogy tudnia kell, melyik három formát futtatja, mielőtt értelmezi a 403-at. A HTTP-ellenőrzési szabályok hozzáadása egy adatfolyam-proxyhoz nem ad neki láthatóságot, és ha egy bájtrelétől várja az eredeti elutasításának magyarázatát, a rossz naplóban fog keresni.
Hasonlítsa össze a proxy kimeneti útvonalát a böngésző alagút-címével
A VPN-hez kapcsolt böngésző nem mozgat automatikusan egy külön proxykiszolgálót arra az alagútra. Az eredeti a proxy kimeneti címét látja, és ha a proxy továbbra is a helyi alapértelmezett útvonalon keresztül lép ki, a védett oldal egy olyan címet lát, amelyre soha nem volt bizalomra beállítva. A laptop belső VPN-címe láthatatlan ennek az eredetinek. Ez a leggyakoribb oka annak, hogy egy működő alagút továbbra is 403-at ad egy olyan oldaltól, amely mindenki más felé helyesen viselkedik.
Tesztelje a két útvonalat külön, hogy a címek ne keveredhessenek.
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/privateAz első kérés azt mutatja, mit válaszol az eredeti a saját címére, a második azt, mit válaszol a proxy címére. Egy egyező 403-pár az eredeti engedélyezési szabályaira mutat; egy 200-at követő 403 a proxy útvonalára mutat. Kérdezze meg az eredeti tulajdonosát, mely forráscímeket engedélyezi valójában a szabálykészlet, ahelyett hogy feltételezné, hogy a VPN-készlet benne van.
Tesztelje minden határt egy azt elkülönítő kéréssel
Különítse el a proxy rétegét azzal, hogy olyasmit kér tőle, amit alkalmazási okokból nem tagadhat meg. Egy CONNECT egy olyan hoszthoz, amelyet a proxy elérhet, az output eldobásával, megmondja, hogy az alagút beengedése egyáltalán működik-e.
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'
Ha ez 200-at ír ki a CONNECT-re, majd egy TLS-kézfogást, a proxy beengedése rendben van, és a későbbi 403 az eredetitől jött. Ha 407-et ír ki, adjon meg proxy-hitelesítő adatokat a --proxy-user használatával, és ismételje meg, mielőtt bármilyen következtetést levon az oldalról. Ha 403-at ír ki a CONNECT sorban, a proxy saját engedélyezési listája a vizsgálandó határ, és az alkalmazás nem érintett.
Tartsa a hitelesítő adatokat a shell-előzményeken és a beillesztett átiratokon kívül. A parancssorba gépelt proxy-jelszó más helyi felhasználók számára látható, és egy hitelesítő adatokkal rögzített CONNECT-nyom rosszabb, mint a nyom hiánya.
Tartsa az ítéletet olvashatónak ahelyett, hogy átírná az oldalt
Miután tudja, melyik komponens utasított el, őrizze meg ezt a választ. Az a fordított proxy, amely az eredeti 403-at 504-es időtúllépésként címkézi át, vagy sikeroldallal helyettesíti, elrejti az engedélyezési döntést egy elérhetőségi történet mögé, és a következő válaszadót a rossz csapathoz küldi. Az egyedi hibaoldalak rendben vannak, ha megtartják az állapotot és kontextust adnak hozzá.
A gyorsítótárazás ugyanilyen gondosságot érdemel. Az RFC 9111 szabályozza, hogyan használhatják újra a megosztott gyorsítótárak a válaszokat, és az egyik hívó számára létrehozott elutasítást nem szabad átadni egy másiknak, mintha engedély lenne. Ha az elutasítási válaszokat egyáltalán tárolják, tartsa azokat privátként és korlátozottan, és soha ne adjon hozzá nyilvános frissességi szabályt csak azért, hogy csökkentse a felsőbb szintű forgalmat.
Fejezze be egy írásos ítélettel, amely megnevezi a komponenst, az általa létrehozott állapotot és azt a forráscímet, amelyet az eredeti látott. Rögzítse a pontos kérést, az érvényben lévő proxybeállításokat és az időpontot, hogy a következő jelentés ugyanazokkal a bizonyítékokkal vethető legyen össze, ahelyett hogy újra a memóriából vezetnék le. Ez a feljegyzés másodpercek alatt válaszol a következő jelentésre, és megakadályozza, hogy ugyanazt a 403-at újra VPN-kiesésként diagnosztizálják.