proxy_redirect ne poveže NGINX z vašim gostiteljem VPN
proxy_redirect prepisuje glave v odgovoru, ki je že prispel; nikoli ne izbere upstreama. Preverite proxy_pass, pot do backenda in nato glave.
Ime vsebuje besedo redirect, zato se prilepi v blok location, ko backend za VPN ni dosegljiv. Nič se ne spremeni, in očiten sklep je, da je direktiva pokvarjena ali potrebuje drugo sintakso. Kar se je v resnici zgodilo, je preprostejše in manj laskavo: proxy_redirect deluje na odgovoru, ki se je že vrnil, in v tej namestitvi nobena zahteva ni prišla tako daleč.
Dve direktivi, dva trenutka v eni zahtevi
Zahteva HTTP skozi obratni proxy po vrsti preide skozi več odločitev, in obe direktivi stojita na nasprotnih koncih tega zaporedja. Ena izbere, kam gre zahteva. Druga ureja določene glave v odgovoru, ki se vrne.
| 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 |
To zaporedje je ves odgovor. Če se druga vrstica nikoli ne izvede, ker je prva spodletela, druga direktiva ni napačno konfigurirana, je preprosto nedosegljiva. Ne glede na to, koliko prepisujete drugo vrstico, odgovor, ki bi ga morala urediti, ne bo nastal. Diagnosticirajte od prve vrstice navzven, in zmedeno vedenje se razkroji v manjkajočo pot ali zavrnjeno povezavo.
Izbira upstreama pripada proxy_pass
Recimo, da NGINX teče na javnem vstopnem gostitelju in prek svojega VPN doseže aplikacijo na 10.40.0.20:8080. Fragment, ki izbere to aplikacijo, izgleda takole, znotraj obstoječega bloka server:
location / {
proxy_pass http://10.40.0.20:8080;
}Uporabite pravo shemo, naslov in vrata ter to obravnavajte kot fragment, ne kot namestitev. Vstopni gostitelj mora držati tudi pot VPN, dovoljeno pot posredovanja in delujoč povratni promet do te storitve, ker proxy, ki na papirju doseže naslov, še vedno potrebuje soglasje jedra.
Referenca modula proxy drži izbiro upstreama ločeno od prepisovanja glav odgovora in opozarja, da vrednost proxy_pass z URI spremeni, kako se nadomesti ujemajoča se predpona location. Dodajanje ali odstranjevanje delov poti brez preverjanja URL-ja, ki ga aplikacija pričakuje, je zanesljiv način za ustvarjanje 404, ki izgleda kot napaka usmerjanja.
proxy_redirect popravi odgovore, ki razkrijejo zasebni naslov
Ko promet steče, lahko backend odgovori z glavo Location, ki navaja njegov zasebni naslov. Brskalnik, ki sledi tej glavi, zapusti javno vstopno točko in poskuša doseči nekaj, česar ne more razrešiti. Namerno konfigurirano prepisovanje odgovora preslika zasebni URL na javnega:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Zamenjajte obe strani z resničnimi vrednostmi. Razumite tudi ozek obseg: ujemajoče se besedilo glav Location in Refresh se prepiše, URL-ji, vdelani v HTML, JavaScript ali prenesene datoteke, pa ne.
Če aplikacija povsod gradi absolutne povezave, je trajna rešitev njena lastna konfiguracija zunanjega URL-ja, ne naraščajoč seznam pravil prepisovanja na proxyju. Dodajanje pravil, dokler izhod ne izgleda prav, ustvari konfiguracijo, ki odpove na prvi strani, ki je nihče ni preizkusil. Ena pravilna nastavitev aplikacije nadomesti celotno zbirko.
Česa prepis glave ne more popraviti
Več sosednjih težav je videti kot težave s preusmerjanjem, pa niso. Glava Host, poslana v upstream, se mora morda ujemati z virtualnim gostiteljem backenda. Upstream TLS lahko zahteva določeno ime strežnika in preverjanje potrdila, prepis glave odgovora pa ne pomaga ne enemu ne drugemu.
Obseg piškotkov in atributi domene pripadajo aplikaciji in njeni konfiguraciji. Proxy lahko ves dan meče ali prepisuje glave in vseeno ustvari sejo, ki odpove pri drugi zahtevi, ker je bil piškotek izdan za gostitelja, ki ga brskalnik ni nikoli obiskal. Ta napaka je videti občasna, zato v čakalni vrsti tako dolgo preživi. Branje domene piškotka običajno konča preiskavo v minuti.
Tudi preverjanje pristnosti in izbiro backenda omejite na predvideno aplikacijo. Javni obratni proxy bi moral izpostaviti eno aplikacijo prek VPN strežnika, ne pa postati splošna prehodna točka do vsakega zasebnega naslova, ki ga ta gostitelj doseže. En sam splošen location, ki posreduje vse, kar klicatelj zahteva, spremeni eno izpostavljeno storitev v zemljevid vašega zasebnega omrežja. Upstream izrecno poimenujte in ga pustite tam.
Preizkusite v vrstnem redu, v katerem potuje zahteva
Po vrsti potrdite tri stvari: NGINX je izbral predvideni location, dokončal zahtevo do backenda, brskalnik pa je sledil vsaki poznejši preusmeritvi in naložil podvire. Vsak korak ima svoje vrstice dnevnika, in branje po vrsti spremeni nejasno 502 v konkretno ugotovitev.
Razlika, ki jo potrebujete, je med neuspešno povezavo z upstreamom in brskalnikom, poslanim na nedosegljivo zasebno ime. Prvo se pojavi v dnevniku napak proxyja; drugo je videti kot zahteva, ki nikoli ne prispe, brskalnik pa se pritožuje čez gostitelja, ki ga ne more razrešiti. Dve različni težavi, dve različni datoteki, in le ena od njiju sploh vključuje proxy_redirect.