proxy_redirect-ek ez du NGINX zure VPN ostalariarekin konektatzen
proxy_redirect-ek jada iritsi den erantzun bateko goiburuak berridazten ditu; ez du inoiz upstreama hautatzen. Egiaztatu proxy_pass, backendera doan ibilbidea eta gero goiburuak.
Izenak redirect hitza du, beraz location bloke batean itsasten da VPNaren atzeko backend bat iristezina denean. Ezer ez da aldatzen, eta ondorio begi-bistakoa direktiba hautsita dagoela edo sintaxi desberdina behar duela da. Benetan gertatu zena sinpleagoa eta gutxiago lausengaria da: proxy_redirect jada itzuli den erantzun baten gainean aritzen da, eta inplementazio honetan ez zen inongo eskaera hain urrun iritsi.
Bi direktiba, bi une eskaera batean
Proxy alderantzizko baten bidezko HTTP eskaera hainbat erabakitatik igarotzen da ordenan, eta bi direktibak sekuentzia horren mutur banatan daude. Batek eskaera nora doan aukeratzen du. Besteak itzultzen den erantzunean zenbait goiburu editatzen ditu.
| 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 |
Ordena hori da erantzun osoa. Bigarren errenkada inoiz exekutatzen ez bada lehenengoa huts egin duelako, bigarren direktiba ez dago gaizki konfiguratuta, besterik gabe iristezina da. Bigarren lerroa nola edo hala berridatzita ere, editatu behar zuen erantzuna ez da sortuko. Diagnostikatu lehen errenkadatik kanpora, eta portaera nahasia falta den ibilbide edo ukatutako konexio bihurtzen da.
Upstreama hautatzea proxy_pass-i dagokio
Demagun NGINX sarrera-host publiko batean exekutatzen dela eta 10.40.0.20:8080 helbideko aplikazio batera iristen dela bere VPNaren bidez. Aplikazio hori hautatzen duen zatiak itxura hau du, lehendik dagoen server bloke baten barruan:
location / {
proxy_pass http://10.40.0.20:8080;
}Erabili benetako eskema, helbidea eta portua, eta tratatu hau zati gisa, ez inplementazio gisa. Sarrera-hostak VPNaren ibilbidea, baimendutako birbidaltze-bidea eta zerbitzu horretarako itzulera-trafiko funtzionala ere eutsi behar ditu, paperean helbide batera iristen den proxy batek kernelaren adostasuna behar baitu oraindik.
proxy moduluaren erreferentziak upstreamaren hautaketa erantzunen goiburuak berridaztetik bereizten du, eta adierazten du URI bat duen proxy_pass balioak aldatu egiten duela bat datorren location aurrizkia nola ordezkatzen den. Bide-osagaiak gehitu edo kentzea aplikazioak espero duen URLa egiaztatu gabe 404 bat sortzeko modu fidagarria da, bideratze-hutsegite itxura duena.
proxy_redirect-ek helbide pribatu bat isurtzen duten erantzunak konpontzen ditu
Trafikoa hasitakoan, backend batek bere helbide pribatua aipatzen duen Location goiburu batekin erantzun dezake. Goiburu horri jarraitzen dion nabigatzaileak sarrera-puntu publikoa uzten du eta ebatzi ezin duen zerbaitetara iristen saiatzen da. Berariaz konfiguratutako erantzun-berridazketak URL pribatua publikoaren gainean mapatzen du:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Ordeztu bi aldeak benetako balioekin. Ulertu esparru estua ere: bat datozen Location eta Refresh goiburuen testua berridazten da, baina HTML, JavaScript edo deskargatutako fitxategietan txertatutako URLak ez.
Aplikazio batek leku guztietan esteka absolutuak eraikitzen baditu, konponbide iraunkorra bere kanpoko URL konfigurazioa da, ez proxian gero eta gehiago diren berridazketa-arauen zerrenda. Irteera zuzena dirudien arte arauak gehitzeak inork probatu ez zuen lehen orrialdean huts egiten duen konfigurazioa sortzen du. Aplikazioaren ezarpen zuzen batek bilduma osoa ordezkatzen du.
Goiburu baten berridazketak konpondu ezin duena
Alboko hainbat arazo berbideratze-arazoak dirudite eta ez dira. Upstreamera bidalitako Host goiburuak backendaren host birtualarekin bat etorri behar du agian. TLS upstream batek zerbitzari-izen zehatza eta ziurtagiria egiaztatzea behar izan ditzake, eta erantzun-goiburu bat berridazteak ez dio horietako bati ere laguntzen.
Cookieen esparrua eta domeinu-atributuak aplikazioari eta haren konfigurazioari dagozkio. Proxy batek egun osoan goiburuak bota edo berridatz ditzake eta hala ere bigarren eskaeran huts egiten duen saio bat sor dezake, cookiea nabigatzaileak inoiz bisitatu ez zuen ostalari batentzat eman zelako. Hutsegite hori tartekakoa dirudi, eta horregatik irauten du hain luze tiketen ilaran. Cookiearen domeinua irakurtzeak minutu batean amaitzen du ikerketa normalean.
Eutsi autentifikazioa eta backendaren hautaketa aurreikusitako aplikaziora mugatuta ere. Proxy alderantzizko publiko batek aplikazio bakarra azaleratu beharko luke zerbitzariaren VPNaren bidez, host horrek irits dezakeen helbide pribatu bakoitzerako atebide orokor bihurtu ordez. Eskaeragileak eskatzen duen guztia birbidaltzen duen location orokor bakar batek zerbitzu azaleratu bat zure sare pribatuaren mapa bihurtzen du. Izenda ezazu upstreama modu esplizituan eta eduki han.
Probatu eskaerak egiten duen ordenan
Egiaztatu hiru gauza segidan: NGINXek aurreikusitako locationa hautatu zuen, backendera eskaera bat osatu zuen, eta nabigatzaileak geroagoko berbideratze bat jarraitu zuen eta azpi-baliabideak kargatu zituen. Urrats bakoitzak bere log-lerroak ditu, eta horiek ordenan irakurtzeak 502 lauso bat aurkikuntza zehatz bihurtzen du.
Behar duzun bereizketa upstream konexio huts baten eta helbide pribatu iristezin batera bidalitako nabigatzaile baten artean dago. Lehenengoa proxyaren errore-logean agertzen da; bigarrena inoiz iristen ez den eskaera gisa agertzen da, nabigatzaileak ebatzi ezin duen ostalari baten inguruan kexu. Bi arazo desberdin, bi fitxategi desberdin, eta horietako batek soilik du zerikusirik proxy_redirect-ekin.