BGP Multipath e rotas de retorno

Question

Provavelmente, sou um n00b completo sobre questões relacionadas a falhas de servidor, mas nosso departamento de TI faz uma declaração ousada que desejo verificar. Eu pesquisei na internet, mas não consigo encontrar nada relacionado à minha pergunta, então eu venho aqui.

Temos o Threat Management Gateway 2010 e costumávamos apenas rotear a solicitação para o IIS e ela continha o endereço IP para que pudéssemos ver de onde ela vinha. Mas agora eles ativaram "Requests apear to the TMG server" para que os endereços IP não sejam mais encaminhados. Cada pedido tem o ip do servidor TMG.

Agora, a idéia por trás disso é que, por causa das rotas bgp do multipath, a solicitação recebida passa pela RouteA, mas as mensagens de confirmação poderiam retornar pela RouteB. A alegação é que, como a solicitação não vem da primeira fonte conhecida, nosso proxy, mas sim do IIS, alguns roteadores inteligentes no visitante de nossos sites não reconhecem a mensagem de confirmação e a filtram. Em outras palavras, a resposta nunca chega.

Mais uma vez, esta é a reivindicação. Mas não consigo encontrar NENHUM recurso na internet que suporte essa afirmação. Eu li sobre o multipath bgp, mas mais no caso de haver rotas alternativas quando a rota mais rápida falha por algum motivo.

Então a afirmação é completamente falsa ou existe (alguma) verdade nisso? Alguém pode me explicar ou me indicar recursos?

Obrigado antecipadamente!

    

Answer 1

Esse tipo de roteamento assimétrico realmente acontece com bastante frequência na internet. Um determinado roteador BGP pode ter uma infinidade de regras de preferências locais, bem como uma perspectiva diferente em um caminho e quais pares prefere usar. Um roteador de internet não sabe ou não se importa com qual canal uma sessão passou e também não importa; contanto que o pacote chegue ao seu destino, tudo está funcionando bem.

Mas esse comportamento não tem nada a ver com a comunicação entre o seu servidor web e o proxy TMG.

A questão com a explicação está aqui:

request doesn't come from the first known source, our proxy, but instead from IIS

Se isso fosse verdade, todas as conexões com o servidor da Web falharão incondicionalmente. O cliente se conecta ao endereço IP do proxy e espera que o tráfego de resposta do mesmo endereço - o servidor IIS sendo o IP de origem do tráfego de resposta (ignorando TMG) obteria o tráfego de resposta rejeitado.

O motivo pelo qual o TMG funciona corretamente para que a aparente fonte da conexão seja o cliente "real" é que o TMG fica alinhado em frente ao seu servidor web (ele só funciona se o TMG estiver em linha, atuando como seu roteador). O TMG vê o tráfego de resposta do seu servidor da Web ligado ao endereço do cliente, o captura e envia para o cliente por meio da conexão correta (aquela que o cliente iniciou no TMG).

Portanto, basicamente, o BGP e o roteamento da Internet não têm nada a ver com isso, mas um tipo semelhante de roteamento assimétrico na sua rede interna (onde o dispositivo TMG não é usado para rotear o tráfego de resposta) interromperia conexões de clientes da Web e necessitar de usar o endereço IP TMG como a fonte de conexão aparente. Talvez eles estejam planejando uma mudança de topologia?