proxy_redirect nesaista NGINX ar jūsu VPN saimnieku
proxy_redirect pārraksta jau atnākušas atbildes galvenes; tas nekad neizvēlas upstream. Pārbaudiet proxy_pass, maršrutu uz backend un pēc tam galvenes.
Nosaukumā ir vārds redirect, tāpēc to ielīmē location blokā, kad aiz VPN esošais backend nav sasniedzams. Nekas nemainās, un acīmredzamais secinājums ir tāds, ka direktīva ir salūzusi vai tai vajag citu sintaksi. Patiesībā notika kas vienkāršāks un mazāk glaimojošs: proxy_redirect strādā ar atbildi, kas jau ir atgriezusies, un šajā izvietojumā neviens pieprasījums tik tālu nenokļuva.
Divas direktīvas, divi mirkļi vienā pieprasījumā
HTTP pieprasījums caur apgriezto starpniekserveri secīgi iziet vairākus lēmumus, un abas direktīvas atrodas pretējos šīs secības galos. Viena izvēlas, kur pieprasījums dosies. Otra rediģē noteiktus galvenes laukus atbildē, kas atgriežas.
| 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 |
Šī secība ir visa atbilde. Ja otrā rinda nekad netiek izpildīta, jo pirmā neizdevās, otrā direktīva nav nepareizi konfigurēta, tā vienkārši nav sasniedzama. Lai cik daudz otrā rinda tiktu pārrakstīta, atbilde, ko tai vajadzēja rediģēt, neradīsies. Diagnosticējiet no pirmās rindas uz āru, un mulsinošā uzvedība izšķīst kā trūkstošs maršruts vai atteikts savienojums.
Upstream izvēle pieder proxy_pass
Pieņemsim, NGINX darbojas publiskā ieejas saimniekā un caur savu VPN sasniedz lietojumprogrammu 10.40.0.20:8080. Fragments, kas izvēlas šo lietojumprogrammu, izskatās šādi, esošā server blokā:
location / {
proxy_pass http://10.40.0.20:8080;
}Izmantojiet īsto shēmu, adresi un portu, un uztveriet to kā fragmentu, nevis izvietojumu. Ieejas saimniekam arī jātur VPN maršruts, atļauts pārsūtīšanas ceļš un strādājoša atgriešanās plūsma uz šo pakalpojumu, jo starpniekserverim, kas uz papīra sasniedz adresi, joprojām vajadzīga kodola piekrišana.
proxy moduļa uzziņa tur upstream izvēli atsevišķi no atbildes galveņu pārrakstīšanas un norāda, ka vērtība proxy_pass ar URI maina to, kā tiek aizstāts atbilstošais location prefikss. Ceļa komponentu pievienošana vai noņemšana, nepārbaudot URL, ko lietojumprogramma sagaida, ir uzticams veids, kā radīt 404, kas izskatās kā maršrutēšanas kļūda.
proxy_redirect labo atbildes, kas noplūdina privātu adresi
Kad plūsma sāk plūst, backend var atbildēt ar galveni Location, kas nosauc tā privāto adresi. Pārlūks, kas seko šai galvenei, atstāj publisko ieejas punktu un mēģina sasniegt kaut ko, ko tas nevar atrisināt. Apzināti konfigurēta atbildes pārrakstīšana kartē privāto URL uz publisko:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Aizstājiet abas puses ar īstām vērtībām. Saprotiet arī šauro tvērumu: atbilstošais galveņu Location un Refresh teksts tiek pārrakstīts, bet URL, kas iegulti HTML, JavaScript vai lejupielādētos failos, netiek.
Ja lietojumprogramma visur būvē absolūtas saites, ilgtspējīgais risinājums ir tās pašas ārējā URL konfigurācija, nevis augošs pārrakstīšanas noteikumu saraksts starpniekserverī. Noteikumu pievienošana, līdz izvade izskatās pareizi, rada konfigurāciju, kas sabrūk pirmajā lapā, ko neviens nav pārbaudījis. Viens pareizs lietojumprogrammas iestatījums aizstāj visu kopumu.
Ko galvenes pārrakstīšana nevar salabot
Vairākas blakus problēmas izskatās kā pāradresācijas problēmas, bet nav. Uz upstream sūtāmā Host galvene var būt jāsaskaņo ar backend virtuālo saimnieku. TLS upstream var prasīt konkrētu servera nosaukumu un sertifikāta pārbaudi, un atbildes galvenes pārrakstīšana nepalīdz nevienam no tiem.
Sīkfailu tvērums un domēna atribūti pieder lietojumprogrammai un tās konfigurācijai. Starpniekserveris var visu dienu izmest vai pārrakstīt galvenes un tomēr radīt sesiju, kas sabrūk otrajā pieprasījumā, jo sīkfails tika izsniegts saimniekam, kuru pārlūks nekad nav apmeklējis. Šī kļūda izskatās periodiska, tāpēc tā tik ilgi izdzīvo biļešu rindā. Sīkfaila domēna nolasīšana parasti pabeidz izmeklēšanu minūtes laikā.
Turiet arī autentifikāciju un backend izvēli ierobežotu ar paredzēto lietojumprogrammu. Publiskam apgrieztajam starpniekserverim vajadzētu atklāt vienu lietojumprogrammu caur servera VPN, nevis kļūt par universāliem vārtiem uz katru privāto adresi, ko šis saimnieks sasniedz. Viens vispārīgs location, kas pārsūta visu, ko pieprasa izsaucējs, pārvērš vienu atklātu pakalpojumu jūsu privātā tīkla kartē. Nosauciet upstream skaidri un turiet to tur.
Pārbaudiet tādā secībā, kādā pieprasījums ceļo
Secīgi apstipriniet trīs lietas: NGINX izvēlējās paredzēto location, pabeidza pieprasījumu uz backend, un pārlūks sekoja jebkurai vēlākai pāradresācijai un ielādēja apakšresursus. Katram solim ir savas žurnāla rindas, un to lasīšana secībā neskaidru 502 pārvērš konkrētā atradumā.
Nepieciešamā atšķirība ir starp neizdevušos upstream savienojumu un pārlūku, kas nosūtīts uz nesasniedzamu privātu nosaukumu. Pirmais parādās starpniekservera kļūdu žurnālā; otrais parādās kā pieprasījums, kas nekad neierodas, un pārlūks sūdzas par saimnieku, ko tas nevar atrisināt. Divas dažādas problēmas, divi dažādi faili, un tikai viena no tām vispār attiecas uz proxy_redirect.