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, эсвэл дотроо мэддэг нэрээр хязгаарлагдсан күүки гаргаж болох бөгөөд тэдгээр бүр хөтчийг хүрч чадахгүй хаяг руу буцаана. Дотоод нэр руу заасан Location толгой нь анхны асуудалтай ижил харагдана, тиймээс түүнийг проксийн гэмтэл гэж буруу оношилдог.

Аппын баримтжуулсан гадаад URL болон түүний прокси сонголтыг тохируулаад, Host толгойг виртуал хост болон гэрчилгээний хүлээлттэй тааруул. Дотоод нэрээр хязгаарлагдсан күүки нийтийн нэрээр буцаж ирэхгүй, дараах нэвтрэх давталт нь баталгаажуулалтын алдаа гэж уншигдана. Эхлээд гадаад URL-ийг сольж, цэвэр хөтчийн профайлаас дахин туршаад, хагас шилжсэн тохиргоо амжилттай нэвтрэлт болон даруй үхэх сессийг үүсгэнэ гэж хүлээ.

Дамжуулсан метадатад зөвхөн томилогдсон проксигоос итгэ. Аливаа клиент тохируулж болох толгой хэзээ ч зөвшөөрлийн утга болох ёсгүй, эс бөгөөс прокси дуудлагч өөр хүний таних тэмдгийг шаардах зам болно. Энэ дүрэм дахин чиглүүлэлтийн асуултаас хамааралгүй бөгөөд дараагийн аливаа дахин загварчлалыг даван туулна.

Танд үнэхээр ямар загвар байгааг шийд

Хэрэв хэрэглэгч бүр аль хэдийн зөвшөөрөгдсөн VPN хандалттай бол хувийн URL руу дахин чиглүүлэх нь санаатай загвар байж болно. Тэр шаардлагыг таамаглахын оронд тодорхой батал, учир нь хоёр загвар огт өөр бүлгүүдэд үйлчилдэг. Тэдний нэг нь зочид буудлын сүлжээнээс огт ажиллахгүй, нөгөө нь аппыг нийтийн URL ачаалж чадах бүхэнд нээдэг. Энэ ялгаа загварын тэмдэглэлд хамаарна.

Шалгалтыг хэрэглэгчдийн сүлжээн дэх машинаас ажиллуулж, хөтчийн хийх хоп бүрийг дага, зөвхөн эхний хариултыг биш. Хаягийн мөр болон дараагийн хүсэлт бүрийг ажигла, учир нь нөөцийн шошгонд нэг үнэмлэхүй URL эхний хоп дамжсан урсгалыг эвдэхэд хангалттай. Нэвтрэлт нийтийн нэрээр ажиллах ёстой, татгалзах ёстой нөөцүүд татгалзагдсан хэвээр байх ёстой.

Урвуу прокси нийтлэх нь тусдаа хандалтын шийдвэр, проксийн өөрийн VPN-ийг нийтийн URL-ийг нь ачаалж чадах бүхэнд ил тод өргөтгөх биш. Диаграм дээр хоёулаа ижил харагдана, хэнийг дотогш оруулахыг зөвшөөрснөөр ялгаатай. Энэ асуудлыг байршуулалтын дараа шийдэх нь дотоод апп санамсаргүйгээр нийтийн болох зам юм.

Хоёрын алийг нь барьснаа, яагаад гэдгийг бичиж үлдээ. Тохиргоонд хүрэх дараагийн хүн нөгөөг нь таамаглана. Тав тухын үүднээс нэмсэн нэг дахин чиглүүлэлт анхны гэмтлийг дахин үүсгэхэд хангалттай бөгөөд шинж тэмдэг яг саяхан зассантайгаа ижил харагдана.