HAProxy 302 cara a unha app privada: quen abre o segundo salto?

Alguén apunta un host público de HAProxy a unha aplicación interna e pregunta por que o navegador non pode seguir. O proxy chega á app pola súa VPN, a redirección devolve unha cabeceira Location e o navegador tenta entón un enderezo que só existe dentro do túnel. Desde fóra a páxina simplemente colga. A decisión é que parte abre a segunda conexión, e iso é o que separa unha redirección dun backend.

Dous camiños que na configuración parecen iguais

Unha redirección remata o intercambio cunha resposta. O cliente le Location e inicia unha petición nova desde onde estea, é dicir, a rede que nunca controlaches. O proxy xa non participa. Todo o que segue depende do DNS, a ruta e a confianza do propio cliente, así que o resultado varía segundo onde o usuario abriu o navegador:

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

Un backend do proxy mantén a segunda etapa no lado do servidor. O proxy ábrea polo camiño que xa ten, e o cliente segue falando cun só nome público. Se o túnel cae, o cliente recibe un erro en lugar dunha URL que non pode seguir. Esa diferenza é tamén o que fai diagnosticable o fallo, porque o erro aparece onde están os rexistros:

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

A documentación de redireccións de HAProxy traza exactamente esa liña: responder ao cliente cunha redirección é unha acción distinta de reenviar a petición a un backend. As dúas directivas están a poucas liñas de distancia nun ficheiro de configuración e compórtanse de forma totalmente distinta. Unha remata a petición e a outra comeza unha segunda que é propiedade do proxy.

O que o navegador necesita e a VPN do servidor non lle dá

A petición do propio navegador necesita catro cousas que quizais non teña: unha resposta DNS para o nome privado, unha ruta cara a ese enderezo, permiso para chegar ao servizo que escoita e confianza no certificado que ese servizo presenta. O host do proxy ten as catro grazas ao seu túnel. Ningunha delas se transfire a un cliente que nunca estivo nese túnel, porque o túnel é unha propiedade do host, non da URL.

Esa fenda explica o síntoma de case funciona. A primeira petición ten éxito, a barra de enderezos cambia e a conexión colga ou falla mentres o proxy está san todo o tempo. Na configuración do proxy non hai nada roto, e axustala non axuda a un cliente que non ten camiño cara a 10.40.0.20. Ou o cliente obtén unha ruta, ou o proxy ten que facer a conexión no seu nome.

Cando só o proxy pode chegar á app

Elimina a acción de redirección e envía esas peticións a un backend que apunte ao enderezo privado. O frontend conserva o seu nome público mentres o backend decide onde vai realmente a petición. Nada do camiño do cliente cambia, porque o proxy deixa de describir un destino e comeza a selo. Para unha aplicación que escoita a propósito no porto interno 8080, o bloque de servidor é curto:

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

Le ese bloque como unha afirmación sobre a táboa de rutas do proxy: 10.40.0.20 debe ser accesible desde o propio host do proxy, o que aquí significa pola interface VPN e non pola ruta por defecto. A palabra clave check só informa do que fai esa ruta, e a ruta de saúde ten que existir na aplicación ou cada sonda marcará o servidor como caído. Unha comprobación correcta non demostra nada sobre o cliente e non substitúe a política que decide quen pode usar o backend.

O fragmento non é un frontend completo. Conserva o listener, a autenticación, a selección de host e ruta permitidos e a regra que decide quen pode chegar á aplicación. Axusta tamén o protocolo do backend, porque un backend HTTPS necesita verificación de certificado e unha configuración de identidade do servidor, e omitir esa comprobación converte unha conexión privada nunha non verificada.

Confirma o camiño de volta en ambos os sentidos antes de declarar a vitoria. A aplicación agora ve unha conexión desde o proxy, así que os seus rexistros e calquera metadato de enderezo do cliente describen o proxy, salvo que organices outra cousa. Decide como se manexan a identidade e os enderezos reenviados, e proba a decisión en lugar de supoñela.

As redireccións da propia app seguen apuntando cara a dentro

Reenviar a primeira petición é só a metade da integración. A aplicación pode emitir redireccións absolutas, URL de recursos codificadas a man ou cookies limitadas ao nome que coñece internamente, e cada unha delas devolve o navegador a un enderezo que non pode alcanzar. Unha cabeceira Location que apunta ao nome interno parece idéntica ao problema orixinal, e por iso se diagnostica mal como un fallo do proxy.

Configura a URL externa documentada da aplicación e as súas opcións de proxy, e despois fai que a cabeceira Host coincida co host virtual e coas expectativas do certificado. Unha cookie limitada ao nome interno non volverá polo nome público, e o bucle de inicio de sesión que segue lese como un erro de autenticación. Cambia primeiro a URL externa, volve probar desde un perfil de navegador limpo e conta con que unha configuración migrada a medias produza un inicio de sesión que funciona e unha sesión que morre de inmediato.

Confía nos metadatos reenviados só desde o proxy designado. Unha cabeceira que calquera cliente pode establecer nunca debe converterse nun valor de autorización, ou o proxy transfórmase nunha vía para que quen chama reclame a identidade doutro. Esa regra é independente da cuestión da redirección e sobrevive a calquera redeseño posterior.

Decide que deseño tes en realidade

Se cada usuario xa ten acceso VPN autorizado, unha redirección a unha URL privada pode ser un deseño deliberado. Confirma ese requisito de forma explícita en lugar de darlo por feito, porque os dous deseños serven poboacións completamente distintas. Un deles non funciona en absoluto desde unha rede de hotel, e o outro expón a aplicación a calquera que poida cargar a URL pública. Esa distinción pertence á nota de deseño.

Executa a comprobación desde unha máquina na rede dos usuarios e segue cada salto que fai o navegador, non só a primeira resposta. Vixía a barra de enderezos e cada petición posterior, porque unha soa URL absoluta nunha etiqueta de recurso abonda para romper un fluxo que o primeiro salto superou. O inicio de sesión ten que funcionar polo nome público, e os recursos que deben denegarse teñen que seguir denegados.

Publicar un proxy inverso é unha decisión de acceso aparte, non unha extensión transparente da VPN do propio proxy a calquera que poida cargar a súa URL pública. Os dous parécense nun diagrama, e difiren en quen pode entrar. Decidir esa cuestión despois do despregamento é como unha aplicación interna se converte en pública por accidente.

Anota cal dos dous construíches e por que. A seguinte persoa que toque a configuración suporá o outro. Abonda unha soa redirección engadida por comodidade para recrear o fallo orixinal, e o síntoma verase exactamente como o que acabas de corrixir.