HAProxy 302 да прыватнай праграмы: хто адкрывае другі скачок?

Перанакіраванне вяртае другое злучэнне браўзеру. Замест гэтага адпраўце запыт на бэкенд, а потым выпраўце ўласныя абсалютныя перанакіраванні і кукі праграмы.

Нехта накіроўвае публічны хост HAProxy на лакальную праграму і пытаецца, чаму браўзер не можа працягнуць. Проксі дасягае праграмы праз свой VPN, перанакіраванне вяртае загаловак Location, і браўзер затым спрабуе адрас, які існуе толькі ўнутры тунеля. Звонку старонка проста завісае. Рашэнне тычыцца таго, які бок адкрывае другое злучэнне, і менавіта гэта адрознівае перанакіраванне ад бэкенда.

Два шляхі, якія падобныя ў канфігурацыі

Перанакіраванне завяршае абмен адказам. Кліент чытае Location і пачынае новы запыт з таго месца, дзе ён знаходзіцца, а гэта сетка, якую вы ніколі не кантралявалі. Проксі больш не ўдзельнічае. Усё далейшае залежыць ад DNS, маршруту і даверу самога кліента, таму вынік залежыць ад таго, дзе карыстальнік адкрыў браўзер:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Бэкенд проксі трымае другі этап на баку сервера. Проксі адкрывае яго па шляху, які ўжо мае, і кліент працягвае размаўляць з адным публічным імем. Калі тунель падае, кліент атрымлівае памылку замест URL, па якім не можа прайсці. Менавіта гэта розніца робіць збой дыягнаставанным, бо памылка з'яўляецца там, дзе знаходзяцца журналы:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

Дакументацыя пра перанакіраванні ад HAProxy праводзіць менавіта гэтую мяжу: адказаць кліенту перанакіраваннем — іншае дзеянне, чым перадаць запыт на бэкенд. Дзве дырэктывы стаяць у канфігурацыйным файле праз некалькі радкоў і паводзяць сябе цалкам па-рознаму. Адна завяршае запыт, другая пачынае другі, які належыць проксі.

Што патрэбна браўзеру і чаго VPN сервера яму не дае

Уласнаму запыту браўзера патрэбныя чатыры рэчы, якіх у яго можа не быць: адказ DNS для прыватнага імя, маршрут да гэтага адраса, дазвол дасягнуць службы, якая слухае, і давер да сертыфіката, які гэтая служба прад'яўляе. Хост проксі мае ўсе чатыры праз свой тунель. Нішто з гэтага не пераходзіць да кліента, які ніколі не быў у гэтым тунелі, бо тунель — уласцівасць хоста, а не URL.

Гэтая прага тлумачыць сімптом амаль-працуе. Першы запыт паспяховы, адрасны радок змяняецца, і затым злучэнне завісае або зрываецца, пакуль проксі ўвесь час здаровы. У канфігурацыі проксі нічога не зламана, і яе наладка не дапаможа кліенту, у якога няма шляху да 10.40.0.20. Або кліент атрымлівае маршрут, або проксі павінен усталяваць злучэнне за яго.

Калі праграму дасягае толькі проксі

Выдаліце дзеянне перанакіравання і адпраўце гэтыя запыты на бэкенд, які паказвае на прыватны адрас. Фронтэнд захоўвае публічнае імя, а бэкенд вырашае, куды насамрэч ідзе запыт. У шляху кліента нічога не мяняецца, бо проксі перастае апісваць прызначэнне і пачынае ім быць. Для праграмы, якая наўмысна слухае ўнутраны порт 8080, блок сервера кароткі:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Чытайце гэты блок як сцвярджэнне пра табліцу маршрутызацыі проксі: 10.40.0.20 мусіць быць дасягальным з самога хоста проксі, што тут азначае праз інтэрфейс VPN, а не праз маршрут па змаўчанні. Ключавое слова check паведамляе толькі пра тое, што робіць гэты маршрут, і шлях здароўя мусіць існаваць у праграме, інакш кожная праверка пазначыць сервер як непрацаздольны. Паспяховая праверка нічога не даказвае пра кліента і не замяняе палітыку, якая вырашае, каму можна карыстацца бэкендам.

Гэты фрагмент — не поўны фронтэнд. Захавайце слухач, аўтэнтыфікацыю, выбар дазволеных хоста і шляхоў, а таксама правіла, якое вырашае, хто наогул можа дасягнуць праграмы. Узгадніце і пратакол бэкенда, бо бэкенд HTTPS патрабуе праверкі сертыфіката і канфігурацыі ідэнтычнасці сервера, а пропуск гэтай праверкі ператварае прыватнае злучэнне ў неправеранае.

Пацвердзіце зваротны шлях у абодвух напрамках, перш чым абвясціць перамогу. Праграма цяпер бачыць злучэнне ад проксі, таму яе журналы і любыя метаданыя адраса кліента апісваюць проксі, калі вы не наладзіце інакш. Вырашыце, як апрацоўваюцца ідэнтычнасць і перададзеныя адрасы, і праверце рашэнне, а не проста прымайце яго.

Уласныя перанакіраванні праграмы па-ранейшаму вядуць унутр

Перадача першага запыту — гэта толькі палова інтэграцыі. Праграма можа выдаваць абсалютныя перанакіраванні, зашытыя ў код URL рэсурсаў або кукі, прывязаныя да імя, якое яна ведае ўнутры, і кожнае з гэтага вяртае браўзер на адрас, дасягнуць які ён не можа. Загаловак Location, які паказвае на ўнутранае імя, выглядае ідэнтычна зыходнай праблеме, таму яго памылкова дыягнастуюць як збой проксі.

Задайце дакументаваны знешні URL праграмы і яе параметры проксі, затым узгадніце загаловак Host з віртуальным хостам і чаканнямі сертыфіката. Кука, прывязаная да ўнутранага імя, не вернецца праз публічнае імя, і цыкл уваходу, які за гэтым ідзе, чытаецца як памылка аўтэнтыфікацыі. Спачатку змяніце знешні URL, ператэстуйце з чыстага профілю браўзера і чакайце, што паўперанесеныя налады дадуць уваход, які ўдаецца, і сесію, якая адразу памірае.

Давярайце перададзеным метаданым толькі ад прызначанага проксі. Загаловак, які можа ўсталяваць любы кліент, ніколі не павінен станавіцца значэннем аўтарызацыі, інакш проксі ператвараецца ў спосаб для выклікальніка выдаць сябе за іншага. Гэтае правіла не залежыць ад пытання перанакіравання і перажывае любы наступны рэдызайн.

Вырашыце, які дызайн вы насамрэч маеце

Калі ў кожнага карыстальніка ўжо ёсць аўтарызаваны доступ да VPN, перанакіраванне на прыватны URL можа быць свядомым дызайнам. Пацвердзіце гэтую патрабу яўна, а не прымайце яе як дадзенае, бо два дызайны абслугоўваюць цалкам розныя групы. Адзін з іх зусім не працуе з гатэльнай сеткі, а другі адкрывае праграму ўсяму, хто можа загрузіць публічны URL. Гэтае адрозненне належыць у нататку пра дызайн.

Правядзіце праверку з машыны ў сетцы карыстальнікаў і прасачыце кожны скачок браўзера, а не толькі першы адказ. Сачыце за адрасным радком і кожным наступным запытам, бо аднаго абсалютнага URL у тэгу рэсурсу дастаткова, каб зламаць паток, які першы скачок прайшоў. Уваход мусіць працаваць праз публічнае імя, а рэсурсы, якія павінны быць забароненыя, мусіць застацца забароненымі.

Публікацыя зваротнага проксі — асобнае рашэнне пра доступ, а не празрыстае пашырэнне ўласнага VPN проксі на ўсіх, хто можа загрузіць яго публічны URL. На схеме яны выглядаюць аднолькава і адрозніваюцца тым, каму дазволена ўвайсці. Вырашаць гэтае пытанне пасля разгортвання — гэта як унутраная праграма выпадкова становіцца публічнай.

Запішыце, які з двух вы пабудавалі і чаму. Наступны чалавек, які дакранецца да канфігурацыі, будзе меркаваць іншы. Аднаго перанакіравання, дададзенага дзеля зручнасці, дастаткова, каб аднавіць зыходны збой, і сімптом будзе выглядаць дакладна як той, які вы толькі што выправілі.

Падобныя артыкулы