proxy_redirect ei ühenda NGINX-it teie VPN-hostiga
proxy_redirect kirjutab ümber juba saabunud vastuse päiseid; see ei vali kunagi upstreami. Kontrollige proxy_pass-i, marsruuti backendini ja seejärel päiseid.
Nimi sisaldab sõna redirect, seega kleebitakse see location-plokki, kui VPN-i taga olev backend ei ole kättesaadav. Midagi ei muutu ja ilmne järeldus on, et direktiiv on katki või vajab teistsugust süntaksit. Tegelikult juhtus midagi lihtsamat ja vähem meelitavat: proxy_redirect töötab vastusega, mis on juba tagasi jõudnud, ja selles juurutusas ei jõudnud ükski päring nii kaugele.
Kaks direktiivi, kaks hetke ühes päringus
HTTP-päring läbi pöördproxy läbib mitu otsust järjest ja kaks direktiivi asuvad selle jada vastaspooltes. Üks valib, kuhu päring läheb. Teine toimetab vastuses teatud päiseid, mis tagasi tulevad.
| 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 |
See järjekord on kogu vastus. Kui teine rida ei käivitu kunagi, sest esimene ebaõnnestus, ei ole teine direktiiv valesti konfigureeritud, vaid lihtsalt kättesaamatu. Ükskõik kui palju teist rida ümber kirjutada, ei teki vastust, mida see pidi toimetama. Diagnoosi esimesest reast väljapoole ja segane käitumine taandub puuduvale marsruudile või tagasilükatud ühendusele.
Upstreami valimine kuulub proxy_pass-ile
Oletame, et NGINX töötab avalikus sisenemishostis ja pääseb oma VPN-i kaudu rakendusele aadressil 10.40.0.20:8080. Seda rakendust valiv fragment näeb välja selline, olemasoleva server-ploki sees:
location / {
proxy_pass http://10.40.0.20:8080;
}Kasutage tegelikku skeemi, aadressi ja porti ning käsitlege seda fragmendina, mitte juurutusena. Sisenemishost peab hoidma ka VPN-marsruuti, lubatud edastusteed ja töötavat tagasiliiklust selle teenuseni, sest proxy, mis pääseb paberil aadressile ligi, vajab ikka kerneli nõusolekut.
Proxy-mooduli viide hoiab upstreami valiku vastuse päiste ümberkirjutamisest lahus ja märgib, et URI-d sisaldav proxy_pass väärtus muudab seda, kuidas vastav location-i prefiks asendatakse. Rajakomponentide lisamine või eemaldamine ilma rakenduse oodatava URL-i kontrollimiseta on usaldusväärne viis tekitada 404, mis näeb välja nagu marsruutimise tõrge.
proxy_redirect parandab vastuseid, mis lekitavad privaatse aadressi
Kui liiklus on käivitunud, võib backend vastata päisega Location, mis nimetab selle privaatset aadressi. Seda päist järgides lahkub brauser avalikust sisenemispunktist ja üritab jõuda millegi juurde, mida see ei suuda lahendada. Teadlikult konfigureeritud vastuse ümberkirjutus kaardistab privaatse URL-i avalikule:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Asendage mõlemad pooled tegelike väärtustega. Mõistke ka kitsast ulatust: sobiv päiste Location ja Refresh tekst kirjutatakse ümber, kuid HTML-i, JavaScripti või allalaaditud failidesse põimitud URL-id mitte.
Kui rakendus ehitab kõikjal absoluutseid linke, on püsiv lahendus selle enda välise URL-i konfiguratsioon, mitte proxy üha pikem ümberkirjutusreeglite loend. Reeglite lisamine, kuni väljund näeb õige välja, annab konfiguratsiooni, mis ebaõnnestub esimesel lehel, mida keegi ei testinud. Üks õige rakenduse säte asendab kogu kogumi.
Mida päise ümberkirjutus parandada ei suuda
Mitmed lähedased probleemid näevad välja nagu ümbersuunamise probleemid, kuid ei ole. Upstreamile saadetav Host-päis võib vajada vastavust backendi virtuaalsele hostile. TLS-upstream võib vajada kindlat serverinime ja sertifikaadi kontrolli ning vastuse päise ümberkirjutamine ei aita kummagi puhul.
Küpsiste ulatus ja domeeni atribuudid kuuluvad rakendusele ja selle konfiguratsioonile. Proxy võib terve päeva päiseid visata või ümber kirjutada ja anda ikkagi sessiooni, mis ebaõnnestub teisel päringul, sest küpsis anti hosti jaoks, mida brauser kunagi ei külastanud. See tõrge näib katkendlikuna, mistõttu püsib see piletijärjekorras nii kaua. Küpsise domeeni lugemine lõpetab uurimise tavaliselt minutiga.
Hoidke autentimine ja backendi valik piiratud kavandatud rakendusega. Avalik pöördproxy peaks ühte rakendust serveri VPN-i kaudu avama, mitte muutuma üldiseks väravaks igale privaatsele aadressile, millele see host pääseb ligi. Üks üldine location, mis edastab kõik, mida kutsuja küsib, muudab ühe avatud teenuse teie privaatvõrgu kaardiks. Nimetage upstream selgelt ja jätke see sinna.
Testige selles järjekorras, kuidas päring liigub
Kinnitage kolm asja järjest: NGINX valis kavandatud locationi, lõpetas päringu backendile ja brauser järgis võimalikku hilisemat ümbersuunamist ning laadis alamressursid. Igal etapil on oma logiread ja nende järjekorras lugemine muudab ebamäärase 502 konkreetseks leiukohaks.
Vajalik eristus on ebaõnnestunud upstream-ühenduse ja kättesaamatule privaatsele nimele saadetud brauseri vahel. Esimene ilmub proxy vealogis; teine näib päringuna, mis ei saabu kunagi, samal ajal kui brauser kurdab hosti üle, mida see ei suuda lahendada. Kaks erinevat probleemi, kaks erinevat faili ja ainult üks neist puudutab üldse proxy_redirecti.