HAProxy 302 жеке колдонмого: экинчи секирүүнү ким ачат?

Бирөө коомдук HAProxy хостун ички колдонмого багыттап, браузер эмнеге ээрчий албайт деп сурайт. Прокси VPN аркылуу колдонмого жетет, кайра багыттоо Location башын кайтарат, анан браузер туннелдин ичинде гана бар даректи сынайт. Сырттан барак жөн гана илинип калат. Чечим экинчи туташууну кайсы тарап ачаары тууралуу, жана дал ошол кайра багыттоону backend-тен ажыратат.

Конфигурацияда окшош көрүнгөн эки жол

Кайра багыттоо алмашууну жооп менен бүтөт. Клиент 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

Проксинин backend-и экинчи этапты сервер тарапта кармайт. Прокси аны өзүндө бар жол менен ачат, ал эми клиент бир коомдук ат менен сүйлөшүүнү улантат. Туннель куласа, клиент ээрчий албаган URL ордуна ката алат. Дал ушул айырма акананы диагностикалануучу кылат, анткени ката журналдар жайгашкан жерде пайда болот:

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

HAProxy'нин кайра багыттоо документтери дал ушул сызыкты тартат: клиентке кайра багыттоо менен жооп берүү сурамды backend-ке өткөрүүдөн башка аракет. Эки директива конфигурация файлында бир нече сап аралыкта турат жана таптакыр башкача жүрүм кылат. Бирөө сурамды бүтүрөт, экинчиси проксиге таандык экинчисин баштайт.

Браузерге эмне керек жана сервердин VPN ага эмнени бербейт

Браузердин өз сурамына анын жок болушу мүмкүн болгон төрт нерсе керек: жеке атка DNS жообу, ошол дарекке маршрут, угуп жаткан кызматка жетүүгө уруксат жана ошол кызмат сунуштаган сертификатка ишеним. Прокси хосттун төртөө тең өз туннели аркылуу бар. Алардын эч бири ошол туннелде эч качан болбогон клиентке өтпөйт, анткени туннель хосттун касиети, URLдин эмес.

Бул ажырым дээрлик-иштейт симптомун түшүндүрөт. Биринчи сурам ийгиликтүү, дарек сабы өзгөрөт, анан прокси бүт убакыт соо болсо да туташуу илинип калат же ийгиликсиз болот. Прокси конфигурациясында эч нерсе сынбаган, жана аны жөндөө 10.40.0.20-га жолу жок клиентке жардам бербейт. Же клиент маршрут алат, же прокси анын ордуна туташууну түзүшү керек.

Прокси гана колдонмого жеткенде

Кайра багыттоо аракетин алып салып, ошол сурамдарды жеке дарекке багыттаган backend-ке жөнөтүңүз. Frontend өзүнүн ачык атын сактайт, ал эми backend сурамдын чынында кайда кетерин чечет. Клиенттин жолунда эч нерсе өзгөрбөйт, анткени прокси барар жерди сүрөттөөнү токтотуп, өзү барар жерге айланат. Ички 8080 портунда атайын угуп жаткан колдонмо үчүн сервер блогу кыска:

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

Бул блокту проксинин маршруттоо таблицасы тууралуу билдирүү катары окуңуз: 10.40.0.20 прокси хосттун өзүнөн жеткиликтүү болушу керек, бул бул жерде демейки маршрут менен эмес, VPN интерфейси аркылуу дегенди билдирет. check ачкыч сөзү гана ошол маршруттун эмне кылаарын билдирет, ал эми ден соолук жолу колдонмодо болушу керек, болбосо ар бир текшерүү серверди өчүк деп белгилейт. Ийгиликтүү текшерүү клиент жөнүндө эч нерсени далилдебейт жана backend-ти ким колдоно аларын чечкен саясатты алмаштырбайт.

Фрагмент толук frontend эмес. Угуучуну, аутентификацияны, уруксат берилген хост жана жол тандоону, жана колдонмого ким жете аларын чечкен эрежени сактаңыз. Backend протоколун да шайкештештириңиз, анткени HTTPS backend сертификатты текшерүүнү жана сервер идентификациясынын конфигурациясын талап кылат, ал эми бул текшерүүнү өткөрүп жиберүү жеке туташууну текшерилбеген туташууга айландырат.

Жеңиш жарыялоодон мурун кайтуу жолун эки багытта тең ырастаңыз. Колдонмо эми проксиден келген туташууну көрөт, ошондуктан анын журналдары жана клиент дарегинин каалаган метаберилиши проксини сүрөттөйт, эгер башкача уюштурбасаңыз. Идентификация жана жиберилген даректер кантип иштетилерин чечиңиз, жана чечимди болжолдоонун ордуна сынап көрүңүз.

Колдонмонун өз кайра багыттоолору али ичке карайт

Биринчи сурамды жөнөтүү интеграциянын жарымы гана. Колдонмо абсолюттук кайра багыттоолорду, катуу коддолгон ресурс URLдерин же ичтен билген атка чектелген cookie файлдарын чыгарышы мүмкүн, жана алардын ар бири браузерди жете албаган дарекке кайтарат. Ички атка багытталган Location башы баштапкы маселе менен бирдей көрүнөт, ошондуктан ал ката катары прокси бузулушу деп диагностикаланат.

Колдонмонун документтелген тышкы URLин жана анын прокси параметрлерин коюңуз, анан Host башын виртуалдык хост жана сертификат күтүүлөрүнө шайкештештириңиз. Ички атка чектелген cookie ачык ат аркылуу кайтпайт, ал эми андан кийинки кирүү цикли аутентификация катасы катары окулат. Адегенде тышкы URLди өзгөртүңүз, таза браузер профилинен кайра текшериңиз, жана жарым көчүрүлгөн параметрлер ийгиликтүү кирүүнү жана дароо өлгөн сессияны жаратат деп күтүңүз.

Жиберилген метаберилиштерге гана дайындалган проксиден ишениңиз. Каалаган клиент коё ала турган баш эч качан авторизация маанисине айланбашы керек, болбосо прокси чакыруучунун башканын идентификациясын талап кылуу жолуна айланат. Бул эреже кайра багыттоо маселесинен көз карандысыз жана кийинки каалаган кайра долбоорлоого туруштук берет.

Сизде чынында кайсы дизайн бар экенин чечиңиз

Эгер ар бир колдонуучунун авторизацияланган VPN жеткилиги болсо, жеке URLге кайра багыттоо атайын дизайн болушу мүмкүн. Бул талапты болжолдоонун ордуна ачык ырастаңыз, анткени эки дизайн таптакыр башка топторго кызмат кылат. Алардын бири мейманкана тармагынан такыр иштебейт, экинчиси колдонмону ачык URLди жүктөй алган ар кимге ачат. Бул айырма дизайн жазуусуна таандык.

Текшерүүнү колдонуучулардын тармагындагы машинадан жүргүзүп, браузер жасаган ар бир секирүүнү ээрчиңиз, биринчи жоопту гана эмес. Дарек сабын жана ар бир кийинки сурамды көзөмөлдөңүз, анткени ресурс тегиндеги бир абсолюттук URL биринчи секирүү өткөн агымды бузууга жетиштүү. Кирүү ачык ат аркылуу иштеши керек, ал эми баш тартылуучу ресурстар баш тартылган бойдон калышы керек.

Тескери проксини жарыялоо өзүнчө жеткилик чечими, проксинин өз VPNин анын ачык URLин жүктөй алган ар кимге тунук кеңейтүү эмес. Диаграммада экөө окшош көрүнөт жана кимге кирүүгө уруксат берилгени менен айырмаланат. Бул маселени орнотуудан кийин чечүү ички колдонмонун кокустан ачык болуп калышынын жолу.

Экөөнүн кайсынысын курганыңызды жана эмне үчүн экенин жазыңыз. Конфигурацияга кийинки тийген адам экинчисин болжолдойт. Ыңгайлуулук үчүн кошулган бир кайра багыттоо баштапкы бузулушту кайра жаратууга жетиштүү, ал эми симптом дал жаңы оңдогонуңузга окшош болот.