proxy_redirect ei yhdistä NGINXiä VPN-hostisi
proxy_redirect kirjoittaa uudelleen jo saapuneen vastauksen otsakkeita; se ei koskaan valitse upstreamia. Tarkista proxy_pass, reitti backendiin ja sitten otsakkeet.
Nimi sisältää sanan redirect, joten se liitetään location-lohkoon, kun VPN:n takana oleva backend ei ole tavoitettavissa. Mikään ei muutu, ja ilmeinen johtopäätös on, että direktiivi on rikki tai tarvitsee eri syntaksin. Se, mitä todella tapahtui, on yksinkertaisempaa ja vähemmän imartelevaa: proxy_redirect toimii vastaukseen, joka on jo palannut, eikä tässä käyttöönotossa mikään pyyntö koskaan päässyt niin pitkälle.
Kaksi direktiiviä, kaksi hetkeä yhdessä pyynnössä
HTTP-pyyntö käänteisen välityspalvelimen kautta kulkee useiden päätösten läpi järjestyksessä, ja kaksi direktiiviä sijaitsee tuon sarjan vastakkaisissa päissä. Toinen valitsee, minne pyyntö menee. Toinen muokkaa tiettyjä otsakkeita vastauksessa, joka palaa.
| 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 |
Tuon järjestys on koko vastaus. Jos toinen rivi ei koskaan suoritu, koska ensimmäinen epäonnistui, toinen direktiivi ei ole väärin konfiguroitu, se on yksinkertaisesti tavoittamaton. Riippumatta siitä, kuinka paljon toista riviä kirjoitetaan uudelleen, vastausta, jota sen oli tarkoitus muokata, ei synny. Diagnosoi ensimmäisestä rivistä ulospäin, ja hämmentävä käytös pelkistyy puuttuvaksi reitiksi tai hylätyksi yhteydeksi.
Upstreamin valinta kuuluu proxy_passille
Oletetaan, että NGINX pyörii julkisella sisääntulohostilla ja tavoittaa sovelluksen osoitteessa 10.40.0.20:8080 VPN:nsä kautta. Sen sovelluksen valitseva katkelma näyttää tältä olemassa olevan server-lohkon sisällä:
location / {
proxy_pass http://10.40.0.20:8080;
}Käytä todellista skeemaa, osoitetta ja porttia ja kohtele tätä katkelmana, älä käyttöönottona. Sisääntulohostin on myös pidettävä VPN-reitti, sallittu edelleenlähetyspolku ja toimiva paluuliikenne tuohon palveluun, koska välityspalvelin, joka tavoittaa osoitteen paperilla, tarvitsee silti ytimen hyväksynnän.
Proxy-moduulin viite pitää upstreamin valinnan erillään vastausotsakkeiden uudelleenkirjoituksesta ja huomauttaa, että URI:n sisältävä proxy_pass-arvo muuttaa sitä, miten vastaava location-etuliite korvataan. Polkukomponenttien lisääminen tai poistaminen tarkistamatta sovelluksen odottamaa URL-osoitetta on luotettava tapa tuottaa 404, joka näyttää reititysvirheeltä.
proxy_redirect korjaa vastauksia, jotka vuotavat yksityisen osoitteen
Kun liikenne virtaa, backend voi vastata Location-otsakkeella, joka nimeää sen yksityisen osoitteen. Otsaketta seuraava selain poistuu julkisesta sisääntulopisteestä ja yrittää tavoittaa jotain, mitä se ei pysty ratkaisemaan. Tarkoituksella konfiguroitu vastauksen uudelleenkirjoitus kuvaa yksityisen URL:n julkiselle:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Korvaa molemmat puolet todellisilla arvoilla. Ymmärrä myös kapea laajuus: vastaavien Location- ja Refresh-otsakkeiden teksti kirjoitetaan uudelleen, mutta HTML:ään, JavaScriptiin tai ladattuihin tiedostoihin upotetut URL:t eivät.
Jos sovellus rakentaa absoluuttisia linkkejä kaikkialle, kestävä ratkaisu on sen oma ulkoisen URL:n konfiguraatio, ei välityspalvelimen kasvava uudelleenkirjoitussääntöjen luettelo. Sääntöjen lisääminen, kunnes tulos näyttää oikealta, tuottaa konfiguraation, joka epäonnistuu ensimmäisellä sivulla, jota kukaan ei testannut. Yksi oikea sovellusasetus korvaa koko kokoelman.
Mitä otsakkeen uudelleenkirjoitus ei voi korjata
Useat läheiset ongelmat näyttävät uudelleenohjausongelmilta eivätkä ole. Upstreamille lähetettävä Host-otsake saattaa vaatia vastaavuutta backendin virtuaalihostin kanssa. TLS-upstream saattaa vaatia tietyn palvelinnimen ja varmenteen vahvistuksen, eikä vastausotsakkeen uudelleenkirjoitus auta kumpaankaan.
Evästeiden laajuus ja toimialueen attribuutit kuuluvat sovellukselle ja sen konfiguraatiolle. Välityspalvelin voi pudottaa tai kirjoittaa otsakkeita uudelleen koko päivän ja tuottaa silti istunnon, joka epäonnistuu toisella pyynnöllä, koska eväste myönnettiin hostille, jota selain ei koskaan käynyt. Tämä vika näyttää ajoittaiselta, ja siksi se säilyy niin kauan tikettijonossa. Evästeen toimialueen lukeminen lopettaa tutkimuksen yleensä minuutissa.
Pidä myös todennus ja backendin valinta rajattuna aiottuun sovellukseen. Julkisen käänteisen välityspalvelimen tulisi tarjota yhtä sovellusta palvelimen VPN:n kautta sen sijaan, että siitä tulisi yleinen yhdyskäytävä jokaiseen yksityiseen osoitteeseen, johon se host pääsee. Yksi yleinen location, joka välittää kaiken, mitä kutsuja pyytää, muuttaa yhden paljastetun palvelun kartaksi yksityisestä verkostasi. Nimeä upstream selkeästi ja pidä se siellä.
Testaa siinä järjestyksessä, jossa pyyntö kulkee
Vahvista kolme asiaa peräkkäin: NGINX valitsi aiotun locationin, se suoritti pyynnön backendille ja selain seurasi mahdollista myöhempää uudelleenohjausta ja latasi aliresurssit. Jokaisella vaiheella on omat lokirivinsä, ja niiden lukeminen järjestyksessä muuttaa epämääräisen 502:n konkreettiseksi havainnoksi.
Tarvitsemasi ero on epäonnistuneen upstream-yhteyden ja tavoittamattomaan yksityiseen nimeen lähetetyn selaimen välillä. Ensimmäinen näkyy välityspalvelimen virhelokissa; toinen näkyy pyyntönä, joka ei koskaan saavu, ja selain valittaa hostista, jota se ei pysty ratkaisemaan. Kaksi eri ongelmaa, kaksi eri tiedostoa, ja vain toinen niistä liittyy lainkaan proxy_redirectiin.