A proxy_redirect nem köti össze a NGINX-et a VPN-hostjával
A proxy_redirect egy már megérkezett válasz fejléceit írja át; soha nem választ upstreamet. Ellenőrizze a proxy_pass-t, a backend felé vezető útvonalat, majd a fejléceket.
A névben benne van a redirect szó, ezért beillesztik egy location blokkba, amikor a VPN mögötti backend nem érhető el. Semmi sem változik, és a kézenfekvő következtetés az, hogy a direktíva hibás, vagy más szintaxist igényel. Valójában egyszerűbb és kevésbé hízelgő dolog történt: a proxy_redirect egy már visszaérkezett válaszon dolgozik, és ebben a telepítésben egyetlen kérés sem jutott addig.
Két direktíva, két pillanat egyetlen kérésben
A fordított proxyn áthaladó HTTP-kérés sorrendben több döntésen megy keresztül, és a két direktíva ennek a sorozatnak az ellentétes végén található. Az egyik kiválasztja, hová megy a kérés. A másik bizonyos fejléceket szerkeszt a visszatérő válaszban.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Ez a sorrend a teljes válasz. Ha a második sor soha nem fut le, mert az első meghiúsult, a második direktíva nincs rosszul beállítva, egyszerűen elérhetetlen. Hiába írjuk át a második sort, a válasz, amelyet szerkesztenie kellett volna, nem jön létre. Diagnosztizáljon az első sortól kifelé, és a zavaró viselkedés hiányzó útvonalra vagy elutasított kapcsolatra bomlik le.
Az upstream kiválasztása a proxy_pass dolga
Tegyük fel, hogy a NGINX egy nyilvános belépési hoston fut, és a VPN-jén keresztül eléri a 10.40.0.20:8080 címen futó alkalmazást. Az alkalmazást kiválasztó részlet így néz ki egy meglévő server blokkon belül:
location / {
proxy_pass http://10.40.0.20:8080;
}Használja a valódi sémát, címet és portot, és kezelje ezt részletként, nem telepítésként. A belépési hostnak a VPN-útvonalat, egy engedélyezett továbbítási útvonalat és a szolgáltatás felé működő visszaforgalmat is tartania kell, mert a papíron címet elérő proxynek még mindig kell a kernel beleegyezése.
A proxy modul referenciája külön tartja az upstream kiválasztását a válaszfejlécek átírásától, és megjegyzi, hogy az URI-t tartalmazó proxy_pass érték megváltoztatja, hogyan cserélődik le a megfelelő location előtag. Útvonal-összetevők hozzáadása vagy eltávolítása az alkalmazás által várt URL ellenőrzése nélkül megbízható módja egy olyan 404 létrehozásának, amely útválasztási hibának látszik.
A proxy_redirect kijavítja a privát címet szivárogtató válaszokat
Amint a forgalom elindul, a backend egy Location fejléccel válaszolhat, amely a privát címét nevezi meg. Az ezt követő böngésző elhagyja a nyilvános belépési pontot, és olyasmit próbál elérni, amit nem tud feloldani. Egy szándékosan beállított válaszátírás a privát URL-t a nyilvánosra képzi le:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Cserélje ki mindkét oldalt valódi értékekre. Értse a szűk hatókört is: a megfelelő Location és Refresh fejlécek szövege átíródik, a HTML-be, JavaScriptbe vagy letöltött fájlokba ágyazott URL-ek viszont nem.
Ha egy alkalmazás mindenhol abszolút hivatkozásokat épít, a tartós megoldás a saját külső URL-konfigurációja, nem a proxyn egyre növekvő átírási szabálylista. A szabályok hozzáadása addig, amíg a kimenet helyesnek látszik, olyan konfigurációt eredményez, amely az első olyan oldalon meghiúsul, amelyet senki nem tesztelt. Egyetlen helyes alkalmazásbeállítás helyettesíti az egész gyűjteményt.
Amit egy fejlécátírás nem tud megjavítani
Több szomszédos probléma úgy néz ki, mint egy átirányítási probléma, és mégsem az. Az upstream felé küldött Host fejlécnek esetleg meg kell felelnie a backend virtuális hostjának. Egy TLS upstreamhez konkrét szervernév és tanúsítvány-ellenőrzés kellhet, és egy válaszfejléc átírása egyiknek sem segít.
A sütik hatóköre és a domain attribútumok az alkalmazáshoz és annak konfigurációjához tartoznak. A proxy egész nap dobálhatja vagy átírhatja a fejléceket, és mégis olyan munkamenetet hoz létre, amely a második kérésnél meghiúsul, mert a sütit olyan hostra adták ki, amelyet a böngésző soha nem látogatott meg. Ez a hiba szakaszosnak tűnik, ezért marad fenn olyan sokáig a hibajegy-sorban. A süti domainjének elolvasása általában egy perc alatt lezárja a vizsgálatot.
Tartsa a hitelesítést és a backend kiválasztását is a tervezett alkalmazásra korlátozva. Egy nyilvános fordított proxynak egyetlen alkalmazást kell kitennie a szerver VPN-jén keresztül ahelyett, hogy általános átjáróvá válna minden privát cím felé, amelyet az a host elér. Egyetlen általános location, amely továbbít mindent, amit a hívó kér, egyetlen kitett szolgáltatást a privát hálózat térképévé alakít. Nevezze meg az upstreamet kifejezetten, és tartsa ott.
Abban a sorrendben teszteljen, ahogyan a kérés halad
Erősítsen meg három dolgot sorrendben: a NGINX a tervezett locationt választotta, befejezett egy kérést a backend felé, és a böngésző követte bármely későbbi átirányítást és betöltötte az alerőforrásokat. Minden lépésnek megvannak a saját naplósorai, és ezek sorrendben olvasása egy homályos 502-t konkrét megállapítássá tesz.
A szükséges megkülönböztetés a sikertelen upstream-kapcsolat és egy elérhetetlen privát névre küldött böngésző között van. Az első a proxy hibanaplójában jelenik meg; a második olyan kérésként, amely soha nem érkezik meg, miközben a böngésző egy hostra panaszkodik, amelyet nem tud feloldani. Két különböző probléma, két különböző fájl, és csak az egyiküknek van köze egyáltalán a proxy_redirecthez.