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

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