HAProxy 302 xususiy ilovaga: ikkinchi sakrashni kim ochadi?

Yo‘naltirish ikkinchi ulanishni brauzerga qaytaradi. So‘rovni buning o‘rniga backendga yuboring, so‘ngra ilovaning o‘z mutlaq yo‘naltirishlari va cookie fayllarini tuzating.

Kimdir ommaviy HAProxy hostini lokal ilovaga yo‘naltiradi va brauzer nega kuzata olmayotganini so‘raydi. Proxy ilovaga o‘z VPN orqali yetib boradi, yo‘naltirish Location sarlavhasini qaytaradi va brauzer keyin faqat tunnel ichida mavjud bo‘lgan manzilni sinab ko‘radi. Tashqaridan sahifa shunchaki osilib qoladi. Qaror ikkinchi ulanishni qaysi tomon ochishiga oid va aynan shu yo‘naltirishni backenddan ajratib turadi.

Konfiguratsiyada bir-biriga o‘xshab ko‘rinadigan ikki yo‘l

Yo‘naltirish almashinuvni javob bilan tugatadi. Klient Locationni o‘qiydi va o‘zi turgan joydan, ya’ni siz hech qachon nazorat qilmagan tarmoqdan yangi so‘rov boshlaydi. Proxy endi ishtirok etmaydi. Keyingi hamma narsa klientning o‘z DNS, marshruti va ishonchiga bog‘liq, shuning uchun natija foydalanuvchi brauzerni qayerda ochganiga qarab farq qiladi:

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

Proxy backend ikkinchi bosqichni server tomonda ushlab turadi. Proxy uni allaqachon mavjud yo‘l orqali ochadi va klient bitta ommaviy nom bilan gaplashishda davom etadi. Tunnel uzilsa, klient kuzata olmaydigan URL o‘rniga xato oladi. Bu farq xatoni tashxislashni ham osonlashtiradi, chunki xato loglar turgan joyda paydo bo‘ladi:

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

HAProxy’ning yo‘naltirish hujjati aynan shu chegarani chizadi: klientga yo‘naltirish bilan javob berish so‘rovni backendga uzatishdan boshqa harakatdir. Ikki direktiva konfiguratsiya faylida bir necha qator masofada turadi va umuman boshqacha ishlaydi. Biri so‘rovni tugatadi, ikkinchisi esa proxy egalik qiladigan ikkinchi so‘rovni boshlaydi.

Brauzerga nima kerak va server VPNi nimani bermaydi

Brauzerning o‘z so‘rovi to‘rtta narsaga muhtoj bo‘lishi mumkin, ular esa yo‘q: xususiy nom uchun DNS javobi, shu manzilga marshrut, tinglayotgan xizmatga yetib borish ruxsati va o‘sha xizmat taqdim etadigan sertifikatga ishonch. Proxy hosti tunneli tufayli to‘rttasiga ham ega. Ularning hech biri o‘sha tunnelda hech qachon bo‘lmagan klientga o‘tmaydi, chunki tunnel URLning emas, hostning xossasidir.

Bu bo‘shliq «deyarli ishlaydi» alomatini tushuntiradi. Birinchi so‘rov muvaffaqiyatli o‘tadi, manzil satri o‘zgaradi va keyin ulanish osilib qoladi yoki uziladi, proxy esa davomida sog‘lom. Proxy konfiguratsiyasida hech narsa buzilmagan va uni sozlash 10.40.0.20 ga yo‘li yo‘q klientga yordam bera olmaydi. Yoki klient marshrut oladi, yoki proxy ulanishni uning nomidan o‘rnatishi kerak.

Ilovaga faqat proxy yetib borganda

Yo‘naltirish harakatini olib tashlang va bu so‘rovlarni xususiy manzilga ishora qiluvchi backendga yuboring. Frontend ommaviy nomini saqlaydi, backend esa so‘rov aslida qayerga ketishini hal qiladi. Klient yo‘lida hech narsa o‘zgarmaydi, chunki proxy manzilni tasvirlashdan to‘xtab, o‘zi manzilga aylanadi. Ataylab ichki 8080 portida tinglayotgan ilova uchun server bloki qisqa:

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

Bu blokni proxy marshrutlash jadvali haqidagi bayonot sifatida o‘qing: 10.40.0.20 ga proxy hostining o‘zidan yetib borish mumkin bo‘lishi kerak, bu yerda esa bu standart marshrut orqali emas, VPN interfeysi orqali degani. check kalit so‘zi faqat shu marshrut nima qilishini bildiradi va sog‘liq yo‘li ilovada mavjud bo‘lishi kerak, aks holda har bir tekshiruv serverni ishlamayotgan deb belgilaydi. Muvaffaqiyatli tekshiruv klient haqida hech narsani isbotlamaydi va backenddan kim foydalanishi mumkinligini hal qiluvchi siyosatni almashtirmaydi.

Bu parcha to‘liq frontend emas. Tinglovchini, autentifikatsiyani, ruxsat etilgan host va yo‘l tanlovini hamda ilovaga umuman kim yetib borishini hal qiluvchi qoidani saqlang. Backend protokolini ham moslang, chunki HTTPS backend sertifikat tekshiruvi va server identiteti konfiguratsiyasini talab qiladi va bu tekshiruvni tashlab ketish xususiy ulanishni tekshirilmagan ulanishga aylantiradi.

G‘alaba e’lon qilishdan oldin qaytish yo‘lini ikki yo‘nalishda ham tasdiqlang. Ilova endi proxy’dan kelgan ulanishni ko‘radi, shuning uchun uning loglari va klient manzili haqidagi har qanday metadata, boshqacha tashkil qilmasangiz, proxy’ni tasvirlaydi. Identitet va uzatilgan manzillar qanday ishlanishini hal qiling va bu qarorni taxmin qilish o‘rniga sinab ko‘ring.

Ilovaning o‘z yo‘naltirishlari hali ham ichkariga ishora qiladi

Birinchi so‘rovni uzatish integratsiyaning faqat yarmi. Ilova mutlaq yo‘naltirishlar, qat’iy kodlangan resurs URLlari yoki ichkarida biladigan nomga bog‘langan cookie fayllarni chiqarishi mumkin va ularning har biri brauzerni yetib borolmaydigan manzilga qaytaradi. Ichki nomga ishora qiluvchi Location sarlavhasi dastlabki muammoga aynan o‘xshaydi, shuning uchun u proxy nosozligi deb noto‘g‘ri tashxis qilinadi.

Ilovaning hujjatlashtirilgan tashqi URL manzilini va uning proxy parametrlarini o‘rnating, so‘ngra Host sarlavhasini virtual host va sertifikat kutilmalariga moslang. Ichki nomga bog‘langan cookie ommaviy nom orqali qaytmaydi va undan keyingi kirish davri autentifikatsiya xatosi deb o‘qiladi. Avval tashqi URLni o‘zgartiring, toza brauzer profilidan qayta sinab ko‘ring va yarim ko‘chirilgan sozlamalar muvaffaqiyatli kirish hamda darhol o‘ladigan sessiya berishini kuting.

Uzatilgan metadataga faqat belgilangan proxy’dan ishoning. Har qanday klient o‘rnatishi mumkin bo‘lgan sarlavha hech qachon avtorizatsiya qiymatiga aylanmasligi kerak, aks holda proxy chaqiruvchining birovning identitetini o‘zlashtirish usuliga aylanadi. Bu qoida yo‘naltirish savolidan mustaqil va har qanday keyingi qayta dizaynda ham saqlanib qoladi.

Sizda qaysi dizayn borligini hal qiling

Agar barcha foydalanuvchilarda allaqachon vakolatli VPN kirish bo‘lsa, xususiy URLga yo‘naltirish ataylab qilingan dizayn bo‘lishi mumkin. Bu talabni taxmin qilish o‘rniga aniq tasdiqlang, chunki ikki dizayn butunlay boshqa auditoriyaga xizmat qiladi. Ulardan biri mehmonxona tarmog‘idan umuman ishlamaydi, ikkinchisi esa ilovani ommaviy URLni yuklay oladigan har kimga ochadi. Bu farq dizayn eslatmasida bo‘lishi kerak.

Tekshiruvni foydalanuvchilar tarmog‘idagi mashinadan ishga tushiring va brauzer qiladigan har bir sakrashni kuzating, faqat birinchi javobni emas. Manzil satrini va har bir keyingi so‘rovni kuzatib boring, chunki resurs tegidagi bitta mutlaq URL birinchi sakrashdan o‘tgan oqimni buzish uchun yetarli. Kirish ommaviy nom orqali ishlashi kerak va rad etilishi kerak bo‘lgan resurslar rad etilgan holicha qolishi kerak.

Teskari proxy nashr qilish alohida kirish qaroridir, proxy’ning o‘z VPNini ommaviy URLini yuklay oladigan har kimga shaffof kengaytirish emas. Diagrammada ikkisi bir xil ko‘rinadi va ular kimning kirishiga ruxsat berilgani bilan farq qiladi. Bu savolni joylashtirishdan keyin hal qilish ichki ilovaning tasodifan ommaviy ilovaga aylanish usulidir.

Qaysi birini qurganingizni va nima uchunligini yozib qo‘ying. Konfiguratsiyaga qo‘l uradigan keyingi odam ikkinchisini taxmin qiladi. Qulaylik uchun qo‘shilgan bitta yo‘naltirish dastlabki nosozlikni qayta yaratish uchun yetarli va alomat xuddi siz hozir tuzatgan narsaga o‘xshaydi.

O'xshash maqolalar