proxy_redirect nuk e lidh NGINX me hostin tuaj VPN
proxy_redirect rishkruan koka në një përgjigje që ka mbërritur tashmë; nuk e zgjedh kurrë upstream-in. Kontrolloni proxy_pass, rrugën drejt backend-it dhe më pas kokave.
Emri përmban fjalën redirect, prandaj ngjitet brenda një blloku location kur një backend pas VPN-së nuk arrihet. Asgjë nuk ndryshon, dhe përfundimi i dukshëm është se direktiva është prishur ose kërkon sintaksë tjetër. Ajo që ndodhi në të vërtetë është më e thjeshtë dhe më pak lëvduese: proxy_redirect vepron mbi një përgjigje që tashmë është kthyer, dhe në këtë vendosje asnjë kërkesë nuk arriti kaq larg.
Dy direktiva, dy momente në një kërkesë
Një kërkesë HTTP përmes një proxy të kundërt kalon në radhë nëpër disa vendime, dhe dy direktivat qëndrojnë në skajet e kundërta të asaj sekuence. Njëra zgjedh ku shkon kërkesa. Tjetra redakton disa koka në përgjigjen që kthehet.
| 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 |
Ai rend është e gjithë përgjigjja. Nëse rreshti i dytë nuk ekzekutohet kurrë sepse i pari dështoi, direktiva e dytë nuk është konfiguruar gabim, ajo është thjesht e paarritshme. Sado që rreshti i dytë të rishkruhet, përgjigjja që duhej të redaktonte nuk do të krijohet. Diagnostiko nga rreshti i parë nga jashtë, dhe sjellja konfuze shndërrohet në një rrugë që mungon ose një lidhje të refuzuar.
Zgjedhja e upstream-it i takon proxy_pass
Supozoni se NGINX punon në një host hyrjeje publik dhe arrin një aplikacion në 10.40.0.20:8080 përmes VPN-së së tij. Fragmenti që zgjedh atë aplikacion duket kështu, brenda një blloku server ekzistues:
location / {
proxy_pass http://10.40.0.20:8080;
}Përdorni skemën, adresën dhe portën reale, dhe trajtojeni këtë si fragment dhe jo si vendosje. Host-i i hyrjes duhet të mbajë gjithashtu rrugën VPN, një shteg përcjelljeje të lejuar dhe trafik kthimi funksional drejt atij shërbimi, sepse një proxy që arrin një adresë në letër ende ka nevojë për pëlqimin e kernelit.
Referenca e modulit proxy mban zgjedhjen e upstream-it të ndarë nga rishkrimi i kokave të përgjigjes, dhe vëren se një vlerë proxy_pass që përmban një URI ndryshon mënyrën se si zëvendësohet prefiksi location që përputhet. Shtimi ose heqja e komponentëve të shtegut pa kontrolluar URL-në që pret aplikacioni është një mënyrë e sigurt për të prodhuar një 404 që duket si dështim rrugëtimi.
proxy_redirect rregullon përgjigjet që zbulojnë një adresë private
Pasi trafiku fillon të rrjedhë, një backend mund të përgjigjet me një kokë Location që emërton adresën e tij private. Një shfletues që ndjek atë kokë largohet nga pika publike e hyrjes dhe përpiqet të arrijë diçka që nuk mund ta zgjidhë. Një rishkrim përgjigjeje i konfiguruar qëllimisht e harton URL-në private mbi atë publike:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Zëvendësoni të dyja anët me vlera reale. Kuptoni edhe shtrirjen e ngushtë: teksti i kokave Location dhe Refresh që përputhen rishkruhet, ndërsa URL-të e futura në HTML, JavaScript ose skedarë të shkarkuar nuk rishkruhen.
Nëse një aplikacion ndërton lidhje absolute kudo, zgjidhja e qëndrueshme është konfigurimi i vetë aplikacionit për URL të jashtme, jo një listë në rritje rregullash rishkrimi në proxy. Shtimi i rregullave derisa dalja të duket e saktë prodhon një konfigurim që dështon në faqen e parë që askush nuk e testoi. Një cilësim i saktë i aplikacionit zëvendëson të gjithë koleksionin.
Çfarë nuk mund të rregullojë një rishkrim koke
Disa probleme fqinje duken si probleme ridrejtimi dhe nuk janë. Koka Host e dërguar drejt upstream-it mund të duhet të përputhet me host-in virtual të backend-it. Një upstream TLS mund të kërkojë një emër specifik serveri plus verifikim certifikate, dhe rishkrimi i një koke përgjigjeje nuk ndihmon asnjërën.
Shtrirja e cookie-ve dhe atributet e domenit i përkasin aplikacionit dhe konfigurimit të tij. Një proxy mund të hedhë ose të rishkruajë koka gjithë ditën dhe prapëseprapë të prodhojë një sesion që dështon në kërkesën e dytë, sepse cookie u lëshua për një host që shfletuesi nuk e vizitoi asnjëherë. Ai dështim duket i ndërprerë, prandaj mbijeton kaq gjatë në radhën e biletave. Leximi i domenit të cookie zakonisht e përfundon hetimin brenda një minute.
Mbani gjithashtu vërtetimin dhe zgjedhjen e backend-it të kufizuara te aplikacioni i synuar. Një proxy i kundërt publik duhet të ekspozojë një aplikacion përmes VPN-së së serverit në vend që të bëhet një portë e përgjithshme drejt çdo adrese private që ai host arrin. Një location i vetëm i përgjithshëm që përcjell gjithçka që kërkon thirrësi e kthen një shërbim të ekspozuar në një hartë të rrjetit tuaj privat. Emërtoni upstream-in në mënyrë eksplicite dhe mbajeni atje.
Testoni sipas rendit që udhëton kërkesa
Konfirmoni tre gjëra me radhë: NGINX zgjodhi location-in e synuar, përfundoi një kërkesë drejt backend-it, dhe shfletuesi ndoqi çdo ridrejtim të mëvonshëm dhe ngarkoi nënburimet. Çdo hap ka rreshtat e vet të logut, dhe leximi i tyre me radhë e kthen një 502 të paqartë në një gjetje konkrete.
Dallimi që ju nevojitet është midis një lidhjeje upstream të dështuar dhe një shfletuesi të dërguar drejt një emri privat të paarritshëm. I pari shfaqet në login e gabimeve të proxy-t; i dyti shfaqet si një kërkesë që nuk mbërrin kurrë, me shfletuesin që ankohet për një host që nuk mund ta zgjidhë. Dy probleme të ndryshme, dy skedarë të ndryshëm, dhe vetëm njëri prej tyre përfshin fare proxy_redirect.