Opções do Farm HAProxy SSL

Question

Estou tentando descobrir como configurar um farm SSL com proxies reversos SSL e haproxy e estou procurando alguns conselhos gerais:

É possível atender a todos os itens abaixo:

• Carregue solicitações de saldo no farm SSL e tenha failover para que mais de uma caixa SSL seja possível (talvez o sslcheck no haproxy ajude isso).
• Obtenha um log HTTP que tenha os endereços IP do cliente reais.
• Não há requisito de TProxy

Se todos os 3 deles não forem possíveis, estou imaginando quais seriam as compensações. No momento, estou considerando algo como o seguinte, mas isso pode mudar:

Frontend de Proxy TCP Haproxy 443 - > Proxies SSL (talvez Nginx) em portas altas - > Front-end HTTP Haproxy - > Webservers

Eu percebo que eu poderia pular o segundo salto de volta para o haproxy, mas a perspectiva única de tudo no HAproxy pode ser legal. Além disso, se eu tiver que usar o TProxy, talvez voltar ao haproxy do farm SSL tornará o roteamento mais simples?

Referências:
link
link

    

Answer 1

Kyle,

Se você precisar apenas de failover para a parte SSL e não de balanceamento de carga, aqui está o que eu sugiro. Você instala haproxy + keepalived + stunnel (corrigido) em dois nós. O keepalived possui o endereço de serviço e verifica a presença dos processos stunnel e haproxy para calcular seu peso, de forma que o nó na melhor forma seja o mestre. O Stunnel recebe o tráfego na porta 443 e o encaminha localmente para o haproxy em qualquer porta que você desejar. Para que o haproxy registre o endereço IP do cliente, você precisa do patch x-forwarded-for stunnel (você pode encontrá-lo no meu site). Você então dirá ao haproxy para registrar o cabeçalho x-forwarded-for.

Existe uma limitação no entanto. Se você suporta HTTP keep-alive, então o stunnel somente adicionará o cabeçalho x-forwarded-for uma vez, o que é um pouco problemático. Na Exceliance, começamos a trabalhar em um patch para encaminhar os parâmetros de conexão de stunnel para haproxy em vez de tocar com o x-forwarded-for. Dessa forma, a haproxy acredita que obtém sua conexão do cliente real. Se estiver interessado, diga-me, podemos enviá-lo para você assim que estiver concluído.

    

Answer 2

OK, estou vendo isso bastante tarde, mas que tal:

      VLAN1         VLAN2

INET -- | -- [SSL] -- | -- [HTTP Load Balancer]
        |             |
        | -- [SSL] -- | -- [WEB01]
        |             |
        | -- [SSL] -- | -- [WEB02]
                      |
                      | -- [WEB03] etc

Em palavras:

• Simple DNS Round Robin para publicar endereços IP x para o serviço,
• Com proxies SSL front-end (Apache, nginx) respondendo diretamente nesses IPs. (Opcional, mas recomendado, com algo como VRRP, CARP ou Linux-HA para garantir alta disponibilidade para esses IPs.)
• Todos os proxies SSL enviam seus pedidos para um balanceador de carga de braço único (para facilidade de configuração, ponto único de gerenciamento de LB / sessão),
• Por fim, o LB envia a solicitação para os servidores de aplicativos da Web.

Algumas coisas surgem:

• O HAProxy e os proxies SSL (nginx) são muito próximos em termos de recursos e usam o modelo nesta arquitetura. Existem outros requisitos para o balanceamento de carga HTTP simples (a limitação de taxa foi mencionada em outro lugar)? Se não, então pode ser mais limpo pular o HAProxy e usar apenas um tipo de servidor para todos os SSL & Manipulação de LB (f.x. nginx).
• O round-robin do DNS provavelmente é "bom o suficiente" por apenas distribuir grosseiramente mais de 2-3 proxies SSL. Mas se você não gostar, você pode usar os mecanismos L4.

Get an HTTP log that has the actual client IP addresses in it.

Supondo que o primeiro dispositivo de nível HTTP adiciona o cabeçalho X-FORWARDED-FOR, e você usa algo como algo como este ou F5's plugins IIS, isso deve funcionar.