Gotchas para configurações de proxy reverso

Question

Executamos vários aplicativos da web, alguns internos, alguns internos / externos. Eu estou montando uma proposta que usamos servidores proxy reverso para isolar os servidores de origem, fornecer terminação SSL e (quando possível) fornecer balanceamento de carga. Para grande parte da nossa configuração, tenho certeza de que funcionará bem, mas temos alguns aplicativos proprietários menos conhecidos que podem precisar de tratamento especial quando avançamos com o proxy reverso.

Que tipos de armadilhas tendem a causar problemas ao mover um servidor de origem de estar na linha de frente para estar atrás de um proxy? (Por exemplo, posso imaginar problemas se um aplicativo precisar saber o endereço IP das solicitações recebidas.)

    

Answer 1

As armadilhas mais frequentes são os redirecionamentos gerados no aplicativo que você terá que reescrever no proxy reverso, o problema do endereço IP do cliente que você já disse, se estiver usando a terminação ssl, talvez o servidor queira verificar o certificado do cliente ou obter informações do usuário . Para o armazenamento em cache de proxy reverso do lado da borda, podem ser necessárias modificações de aplicativo (adecuar cabeçalhos de expiração, cookies desnecessários não selecionados, etc.). Se você estiver usando a autenticação integrada do Windows, ela pode ser inatingível ou um verdadeiro pesadelo

Então você pode ter problemas de tunning, mas acho que isso será muito mais fácil de resolver. Meu conjunto de ferramentas preferido para essa tarefa seria:

• Nginx na camada externa para virtual gerenciamento de hospedagem e localização mapeamento, compactação, ssl, acesso logging
• verniz para armazenamento em cache
• haproxy para enfileiramento de solicitações, balanceamento de carga e verificação de backend.
• Se você precisar de alta disponibilidade para sua (s) caixa (s) de proxy reverso, o trabalho será feito

Answer 2

Problemas que você pode ter com aplicativos por trás de um proxy reverso:

1. Se o idioma ou o aplicativo usar endereços IP para manter as sessões, o único endereço IP que chega ao aplicativo será o proxy. Usando nginx e varnish , você pode adicionar o cabeçalho X-Forwarded-for ao endereço IP original e fazer com que o aplicativo o reconheça.
2. O gerenciamento de sessões em ambientes com carga balanceada é complicado. Você deve usar um recurso compartilhado para que os servidores mantenham as informações da sessão para que um usuário logado possa acessar qualquer um dos back-ends de um aplicativo com carga balanceada e manter sua sessão. Bancos de dados e Memcached são opções populares para compartilhamento de sessão.
3. Se o aplicativo com proxy reverso usar URLs absolutos em suas respostas, eles poderão quebrar a regravação no proxy. Ou seja um aplicativo que faz 302 redireciona para um URL diferente do proxy.

Atualmente, uso nginx no frontend e verniz por trás dele para fazer proxy e balanceamento de carga / verificação de back-end. Como um ponto único de falha, é muito importante usar uma solução de cluster no balanceador de carga / proxy reverso.

Eu uso o corosync / pacemaker (Linux HA, versão mais recente) para balanceamento de carga dos balanceadores de carga: três balanceadores de carga, cada um um com um endereço IP externo, RR balanceado usando DNS (um nome aponta para os três endereços IP). Se uma das máquinas estiver inativa, o endereço IP designado para ela será movido pelo corosync para uma das outras duas máquinas restantes. Além disso, se eu adicionar mais máquinas / endereços IP, eles serão automaticamente balanceados e, se todas as máquinas, com exceção de uma, estiverem desativadas, todos os IPs estarão ativos. Você pode usar o corosync para fazer configurações ativo-ativo, ativo-passivo e muitas outras configurações de cluster.

    

Answer 3

Uma maneira comum (e barata) de fazer isso é usar o squid como um proxy reverso ... você deve dar uma olhada no seu FAQ onde eles discutem problemas comuns. Perguntas frequentes sobre o proxy do SQL Server

    

Answer 4

Você também pode enfrentar problemas com redirecionamentos internos: o proxy fará com que o aplicativo "pense" que está localizado em um URL, que obviamente é diferente do URL real (externo)

    

Answer 5

No Linux / BSD e em alguns outros sistemas operacionais é bem possível que o proxy se disfarça como o ip do cliente - assim você não perde a visibilidade (isso usa as funções de rede do sistema operacional - iptables / ipfw - não o proxy). / p>

Se você estiver usando a autenticação de certificado de cliente em um dos aplicativos, terá dificuldade em deslocar o ponto de terminação SSL e manter a segurança.

O balanceamento de carga pode ser complicado - para aplicativos http, você precisa replicar o estado em tempo real no cluster - ou usar 'sessões fixas' que prejudicam o princípio da tolerância a falhas (uma abordagem híbrida usando replicação / O failover de sessão definido geralmente é a solução mais prática).