HAProxy 302 жеке қолданбаға: екінші секірісті кім ашады?

Қайта бағыттау екінші қосылымды браузерге қайтарады. Оның орнына сұранысты backend-ке жіберіңіз, содан кейін қолданбаның өзінің абсолютті қайта бағыттаулары мен cookie файлдарын түзетіңіз.

Біреу жалпыға ашық 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-ін жүктей алатын кез келгенге мөлдір кеңейту емес. Диаграммада екеуі ұқсас көрінеді және кімге кіруге рұқсат етілгенімен ерекшеленеді. Бұл мәселені орналастырудан кейін шешу ішкі қолданбаның кездейсоқ ашық болып қалу жолы.

Екеуінің қайсысын салғаныңызды және неге екенін жазыңыз. Конфигурацияға келесі тиген адам екіншісін болжайды. Ыңғайлылық үшін қосылған бір қайта бағыттау бастапқы ақауды қайта жасауға жеткілікті, ал симптом дәл жаңа түзеткеніңізге ұқсайды.

Қатысты мақалалар