proxy_redirect не злучае NGINX з вашым VPN-хостам
proxy_redirect перапісвае загалоўкі ў адказе, які ўжо прыйшоў; ён ніколі не выбірае upstream. Праверце proxy_pass, маршрут да backend, потым загалоўкі.
У назве ёсць слова redirect, таму яго ўстаўляюць у блок location, калі backend за VPN недасяжны. Нічога не змяняецца, і відавочная выснова — дырэктыва зламана або патрабуе іншага сінтаксісу. Насамрэч адбылося прасцей і менш прыемна: proxy_redirect працуе з адказам, які ўжо вярнуўся, а ў гэтым разгортванні ніводны запыт датуль не дайшоў.
Дзве дырэктывы, два моманты ў адным запыце
HTTP-запыт праз зваротны проксі праходзіць некалькі рашэнняў па парадку, і дзве дырэктывы знаходзяцца на процілеглых канцах гэтай паслядоўнасці. Адна выбірае, куды пойдзе запыт. Другая рэдагуе пэўныя загалоўкі ў адказе, які вяртаецца.
| 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 |
Гэтая чарговасць і ёсць увесь адказ. Калі другі радок ніколі не выконваецца, бо першы не спрацаваў, другая дырэктыва не наладжана няправільна — яна проста недасяжная. Колькі б вы ні перапісвалі другі радок, адказ, які ён павінен быў адрэдагаваць, не зявіцца. Дыягнастуйце ад першага радка вонкі, і заблытаныя паводзіны зводзяцца да адсутнага маршруту або адхіленага злучэння.
Выбар upstream належыць proxy_pass
Выкажам здагадку, што NGINX працуе на публічным уваходным хасце і можа дасягнуць прыкладання па 10.40.0.20:8080 праз свой VPN. Фрагмент, які выбірае гэтае прыкладанне, выглядае так, унутры існуючага блока server:
location / {
proxy_pass http://10.40.0.20:8080;
}Выкарыстоўвайце сапраўдную схему, адрас і порт і стаўцеся да гэтага як да фрагмента, а не да разгортвання. Уваходны хост таксама павінен трымаць маршрут VPN, дазволены шлях перасылкі і працоўны зваротны трафік да гэтай службы, бо проксі, які можа дасягнуць адраса на паперы, усё яшчэ патрабуе згоды ядра.
Даведка модуля proxy трымае выбар upstream асобна ад перапісвання загалоўкаў адказу і адзначае, што значэнне proxy_pass з URI змяняе тое, як замяняецца адпаведны прэфікс location. Даданне або выдаленне кампанентаў шляху без праверкі чаканага URL прыкладання — надзейны спосаб атрымаць 404, які выглядае як памылка маршрутызацыі.
proxy_redirect выпраўляе адказы, якія выдаюць прыватны адрас
Калі трафік пайшоў, backend можа адказаць загалоўкам Location са сваім прыватным адрасам. Браўзер, які ідзе за гэтым загалоўкам, пакідае публічную кропку ўваходу і спрабуе дасягнуць таго, што не можа развязаць. Наўмысна наладжанае перапісванне адказу адлюстроўвае прыватны URL на публічны:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Замяніце абодва бакі сапраўднымі значэннямі. Разумейце і вузкі ахоп: адпаведны тэкст загалоўкаў Location і Refresh перапісваецца, а URL, убудаваныя ў HTML, JavaScript або спампаваныя файлы, не.
Калі прыкладанне будуе абсалютныя спасылкі ўсюды, доўгатэрміновае рашэнне — уласная канфігурацыя знешняга URL, а не ростучы спіс правіл перапісвання на проксі. Даданне правілаў, пакуль вынік не пачне выглядаць правільна, стварае канфігурацыю, якая зламаецца на першай жа старонцы, якую ніхто не праверыў. Адна правільная налада прыкладання замяняе ўвесь набор.
Што перапісванне загалоўка не можа выправіць
Некалькі суседніх праблем выглядаюць як праблемы перанакіравання, але імі не зяўляюцца. Загаловак Host, які адпраўляецца upstream, можа патрабаваць адпаведнасці віртуальнаму хасцу backend. TLS-upstream можа патрабаваць пэўнай назвы сервера і праверкі сертыфіката, і перапісванне загалоўка адказу не дапамагае ні таму, ні іншаму.
Ахоп кукі і атрыбуты домена належаць прыкладанню і яго канфігурацыі. Проксі можа цэлы дзень скідаць або перапісваць загалоўкі і ўсё роўна выдаць сесію, якая зламаецца на другім запыце, бо кукі выдадзены для хоста, на якім браўзер ніколі не быў. Такая памылка выглядае перыядычнай, таму яна так доўга жыве ў чарзе заявак. Чытанне домена кукі звычайна завяршае расследаванне за хвіліну.
Трымайце аўтэнтыфікацыю і выбар backend абмежаванымі мэтавым прыкладаннем. Публічны зваротны проксі павінен адкрываць адно прыкладанне праз VPN сервера, а не станавіцца ўніверсальным шлюзам да кожнага прыватнага адраса, дасяжнага з гэтага хоста. Адзін агульны location, які перасылае ўсё, што просіць выклікальнік, пераўтварае адну адкрытую службу ў карту вашай прыватнай сеткі. Назавіце upstream яўна і пакіньце яго там.
Тэстуйце ў тым парадку, у якім ідзе запыт
Пацвердзіце тры рэчы па чарзе: NGINX выбраў патрэбны location, завяршыў запыт да backend, а браўзер пайшоў за наступным перанакіраваннем і загрузіў падрэсурсы. Кожны крок мае свае радкі лога, і чытанне іх па парадку ператварае неакрэслены 502 у канкрэтную знаходку.
Патрэбнае вам размежаванне — паміж няўдалым злучэннем з upstream і браўзерам, адпраўленым да недасяжнай прыватнай назвы. Першае зяўляецца ў логу памылак проксі; другое выглядае як запыт, які ніколі не прыходзіць, а браўзер скардзіцца на хост, які не можа развязаць. Дзве розныя праблемы, два розныя файлы, і толькі адна з іх наогул датычыць proxy_redirect.