Nid yw proxy_redirect yn cysylltu NGINX â'ch host VPN

Mae'r enw'n cynnwys y gair redirect, felly caiff ei ludo i mewn i floc location pan na ellir cyrraedd backend y tu ôl i'r VPN. Nid oes dim yn newid, a'r casgliad amlwg yw bod y gyfarwyddeb wedi torri neu fod angen cystrawen wahanol. Yr hyn a ddigwyddodd sy'n symlach ac yn llai canmoliaethus: mae proxy_redirect yn gweithio ar ymateb sydd eisoes wedi dod yn ôl, ac yn y lleoliad hwn ni chyrhaeddodd unrhyw gais mor bell.

Dwy gyfarwyddeb, dau eiliad mewn un cais

Mae cais HTTP trwy brocsi gwrthdro yn mynd trwy sawl penderfyniad yn drefnus, ac mae'r ddwy gyfarwyddeb yn byw ar ddau ben y dilyniant hwnnw. Mae un yn dewis i ble mae'r cais yn mynd. Mae'r llall yn golygu rhai penawdau yn yr ateb sy'n dychwelyd.

Y drefn honno yw'r ateb cyfan. Os na fydd yr ail res byth yn rhedeg oherwydd bod y cyntaf wedi methu, nid yw'r ail gyfarwyddeb wedi'i ffurfweddu'n anghywir, mae'n syml yn anghyrhaeddadwy. Ni waeth faint o ailysgrifennu ar yr ail linell, ni fydd yn creu'r ymateb y dylai fod wedi'i olygu. Diagnoswch o'r rhes gyntaf tuag allan, ac mae'r ymddygiad dryslyd yn datrys i lwybr coll neu gysylltiad wedi'i wrthod.

Dewis yr upstream sy'n perthyn i proxy_pass

Gadewch i ni dybio bod NGINX yn rhedeg ar host mynediad cyhoeddus ac yn gallu cyrraedd cymhwysiad yn 10.40.0.20:8080 dros ei VPN. Mae'r darn sy'n dewis y cymhwysiad hwnnw'n edrych fel hyn, y tu mewn i floc server sy'n bodoli eisoes:

location / {
    proxy_pass http://10.40.0.20:8080;
}

Defnyddiwch y cynllun, y cyfeiriad a'r porthladd go iawn, a thriniwch hyn fel darn yn hytrach na lleoliad. Rhaid i'r host mynediad hefyd ddal y llwybr VPN, llwybr anfon a ganiateir, a thraffig dychwelyd sy'n gweithio i'r gwasanaeth hwnnw, oherwydd mae proesi sy'n gallu cyrraedd cyfeiriad ar bapur yn dal i fod angen cytundeb y cnewyllyn.

Mae cyfeirlyfr y modiwl proxy yn cadw dewis upstream ar wahân i ailosod penawdau ymateb, ac yn nodi bod gwerth proxy_pass sy'n cynnwys URI yn newid sut y caiff y rhagddodiad location cyfatebol ei ddisodli. Mae ychwanegu neu dynnu cydrannau llwybr heb wirio'r URL y mae'r cymhwysiad yn ei ddisgwyl yn ffordd ddibynadwy o gynhyrchu 404 sy'n edrych fel methiant llwybro.

Mae proxy_redirect yn trwsio atebion sy'n gollwng cyfeiriad preifat

Unwaith y bydd traffig yn llifo, gall backend ateb gyda phenawd Location sy'n enwi ei gyfeiriad preifat. Mae porwr sy'n dilyn y penawd hwnnw'n gadael y pwynt mynediad cyhoeddus ac yn ceisio cyrraedd rhywbeth na all ei ddatrys. Mae ailosodiad ymateb a ffurfweddwyd yn fwriadol yn mapio'r URL preifat ar yr un cyhoeddus:

proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;

Disodlwch y ddwy ochr â gwerthoedd go iawn. Deallwch y cwmpas cul hefyd: mae testun y penawdau Location a Refresh sy'n cyfateb yn cael ei ailosod, ond nid yw URLau sydd wedi'u mewnosod mewn HTML, JavaScript na ffeiliau a lawrlwythwyd.

Os yw cymhwysiad yn adeiladu dolenni absoliwt ym mhob man, y gwelliant parhaol yw ei ffurfweddiad URL allanol ei hun, nid rhestr gynyddol o reolau ailosod ar y proesi. Mae ychwanegu rheolau nes bod yr allbwn yn edrych yn iawn yn cynhyrchu ffurfweddiad sy'n methu ar y dudalen gyntaf na phrofodd neb hi. Mae un gosodiad cymhwysiad cywir yn disodli'r casgliad cyfan.

Yr hyn na all ailosodiad penawd ei drwsio

Mae sawl problem gyfagos yn edrych fel problemau ailgyfeirio ac nid ydynt. Efallai y bydd angen i'r penawd Host a anfonir i'r upstream gyd-fynd â host rhithwir y backend. Efallai y bydd angen enw gweinydd penodol ynghyd â dilysu tystysgrif ar upstream TLS, ac nid yw ailosod penawd ymateb yn gwneud dim i'r naill na'r llall.

Mae cwmpas cwcis a nodweddion parth yn perthyn i'r cymhwysiad a'i ffurfweddiad. Gall proesi ollwng neu ailosod penawdau drwy'r dydd ac eto gynhyrchu sesiwn sy'n methu ar yr ail gais, oherwydd bod y cwci wedi'i gyhoeddi ar gyfer host na ymwelodd y porwr ag ef erioed. Mae'r methiant hwnnw'n edrych yn ysbeidiol, a dyna pam mae'n goroesi cyhyd mewn ciw tocynnau. Mae darllen parth y cwci fel arfer yn gorffen yr ymchwiliad mewn munud.

Cadwch ddilysu a dewis backend yn gyfyngedig i'r cymhwysiad a fwriadwyd hefyd. Dylai proesi gwrthdro cyhoeddus amlygu un cymhwysiad trwy VPN y gweinydd yn hytrach na dod yn borth cyffredinol i bob cyfeiriad preifat y gall y host hwnnw ei gyrraedd. Mae un location cyffredinol sy'n anfon popeth y mae'r galwr yn gofyn amdano yn troi un gwasanaeth agored yn fap o'ch rhwydwaith preifat. Enwch yr upstream yn benodol a'i gadw yno.

Profwch yn y drefn y mae'r cais yn teithio

Cadarnhewch dri pheth yn olynol: dewisodd NGINX y location a fwriadwyd, cwblhaodd gais i'r backend, a dilynodd y porwr unrhyw ailgyfeiriad diweddarach a llwytho'r is-adnoddau. Mae gan bob cam ei linellau log ei hun, ac mae eu darllen yn drefnus yn troi 502 annelwig yn ddarganfyddiad penodol.

Y gwahaniaeth sydd ei angen arnoch yw rhwng cysylltiad upstream a fethodd a phorwr a anfonwyd at enw preifat anghyrhaeddadwy. Mae'r cyntaf yn ymddangos yn log gwallau'r proesi; mae'r ail yn ymddangos fel cais nad yw byth yn cyrraedd, gyda'r porwr yn cwyno am host na all ei ddatrys. Dau broblem wahanol, dwy ffeil wahanol, a dim ond un ohonynt sy'n cynnwys proxy_redirect o gwbl.