proxy_redirect nejungia NGINX prie jūsų VPN hosto
proxy_redirect perrašo jau atėjusio atsakymo antraštes; jis niekada nepasirenka upstream. Patikrinkite proxy_pass, maršrutą į backend, tada antraštes.
Pavadinime yra žodis redirect, todėl jis įklijuojamas į location bloką, kai backend už VPN nepasiekiamas. Niekas nesikeičia, ir akivaizdi išvada – direktyva sulaužyta arba reikia kitos sintaksės. Iš tikrųjų nutiko paprasčiau ir mažiau pagirtinai: proxy_redirect dirba su atsakymu, kuris jau grįžo, o šiame diegime nė viena užklausa taip toli nenuejo.
Dvi direktyvos, du momentai vienoje užklausoje
HTTP užklausa per atvirkštinį tarpinį serverį iš eilės praeina kelis sprendimus, o abi direktyvos yra priešinguose tos sekos galuose. Viena pasirenka, kur užklausa keliaus. Kita redaguoja tam tikras antraštes atsakyme, kuris grįžta.
| 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 |
Ši tvarka ir yra visas atsakymas. Jei antroji eilutė niekada neįvykdoma, nes pirmoji nepavyko, antroji direktyva ne neteisingai sukonfigūruota, ji tiesiog nepasiekiama. Kad ir kiek perrašinėtumėte antrąją eilutę, atsakymas, kurį ji turėjo redaguoti, neatsiras. Diagnozuokite nuo pirmosios eilutės į išorę, ir painus elgesys susiveda į trūkstamą maršrutą arba atmestą ryšį.
Upstream pasirinkimas priklauso proxy_pass
Tarkime, NGINX veikia viešame įėjimo hoste ir pasiekia programą adresu 10.40.0.20:8080 per savo VPN. Fragmentas, kuris pasirenka tą programą, atrodo taip, esamame server bloke:
location / {
proxy_pass http://10.40.0.20:8080;
}Naudokite tikrą schemą, adresą ir prievadą, ir traktuokite tai kaip fragmentą, o ne diegimą. Įėjimo hostas taip pat turi laikyti VPN maršrutą, leidžiamą persiuntimo kelią ir veikiantį grįžtamąjį srautą į tą paslaugą, nes tarpinis serveris, kuris popieriuje pasiekia adresą, vis tiek turi gauti branduolio sutikimą.
proxy modulio nuoroda laiko upstream pasirinkimą atskirai nuo atsakymo antraščių perrašymo ir pažymi, kad reikšmė proxy_pass su URI keičia tai, kaip pakeičiamas atitinkamas location priešdėlis. Kelio komponentų pridėjimas ar pašalinimas netikrinus URL, kurio tikisi programa, yra patikimas būdas sukurti 404, kuris atrodo kaip maršrutizavimo gedimas.
proxy_redirect taiso atsakymus, kurie nuteka privatų adresą
Kai srautas pradeda tekėti, backend gali atsakyti antrašte Location, kurioje nurodytas jo privatus adresas. Naršyklė, kuri seka šią antraštę, palieka viešą įėjimo tašką ir bando pasiekti tai, ko negali išspręsti. Sąmoningai sukonfigūruotas atsakymo perrašymas susieja privatų URL su viešu:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Pakeiskite abi puses tikromis reikšmėmis. Supraskite ir siaurą apimtį: atitinkamas antraščių Location ir Refresh tekstas perrašomas, o URL, įterpti į HTML, JavaScript ar atsisiųstus failus, ne.
Jei programa visur kuria absoliučias nuorodas, ilgalaikis sprendimas yra jos pačios išorinio URL konfigūracija, o ne augantis perrašymo taisyklių sąrašas tarpiniame serveryje. Taisyklių pridėjimas tol, kol išvestis atrodo teisingai, sukuria konfigūraciją, kuri sugenda pirmame puslapyje, kurio niekas neišbandė. Vienas teisingas programos nustatymas pakeičia visą rinkinį.
Ko antraštės perrašymas nepataisys
Keli gretimi galvosūkiai atrodo kaip peradresavimo problemos, bet nėra. Į upstream siunčiama Host antraštė gali turėti atitikti backend virtualų hostą. TLS upstream gali reikalauti konkretaus serverio vardo ir sertifikato patikros, o atsakymo antraštės perrašymas nepadeda nė vienam.
Slapukų apimtis ir domeno atributai priklauso programai ir jos konfigūracijai. Tarpinis serveris gali visą dieną išmesti ar perrašyti antraštes ir vis tiek sukurti sesiją, kuri sugenda antroje užklausoje, nes slapukas buvo išduotas hostui, kurio naršyklė niekada nelankė. Šis gedimas atrodo pasikartojantis, todėl taip ilgai laikosi bilietų eilėje. Slapuko domeno perskaitymas paprastai baigia tyrimą per minutę.
Taip pat laikykite autentifikavimą ir backend pasirinkimą apribotus numatytai programai. Viešas atvirkštinis tarpinis serveris turėtų atskleisti vieną programą per serverio VPN, o ne tapti universaliu vartais į kiekvieną privatų adresą, kurį tas hostas pasiekia. Vienas bendras location, kuris persiunčia viską, ko prašo kvietėjas, vieną atskleistą paslaugą paverčia jūsų privataus tinklo žemėlapiu. Įvardykite upstream aiškiai ir laikykite jį ten.
Bandykite ta tvarka, kuria keliauja užklausa
Iš eilės patvirtinkite tris dalykus: NGINX pasirinko numatytą location, užbaigė užklausą į backend, o naršyklė sekė bet kokį vėlesnį peradresavimą ir įkėlė papildomus išteklius. Kiekvienas žingsnis turi savo žurnalo eilutes, o jų skaitymas iš eilės neaiškų 502 paverčia konkrečiu radiniu.
Jums reikalingas skirtumas yra tarp nepavykusio upstream ryšio ir naršyklės, nusiųstos į nepasiekiamą privatų vardą. Pirmasis pasirodo tarpinio serverio klaidų žurnale; antrasis pasirodo kaip užklausa, kuri niekada neatvyksta, o naršyklė skundžiasi hostu, kurio negali išspręsti. Dvi skirtingos problemos, du skirtingi failai, ir tik viena iš jų apskritai susijusi su proxy_redirect.