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. На дијаграму те две ствари изгледају исто, а разликују се по томе коме је дозвољен улаз. Одлучивање о том питању после распоређивања је начин да унутрашња апликација случајно постане јавна.

Запишите шта сте изградили и зашто. Следећа особа која дотакне конфигурацију претпоставиће оно друго. Једно преусмеравање додато ради удобности довољно је да поново створи првобитни отказ, а симптом ће изгледати тачно као онај који сте управо исправили.

Повезани чланци