Detecção do gateway inativo no Windows 2008 Server

Question

Nós implementamos recentemente o HAProxy para stackoverflow.com. Decidimos usar o TProxy para manter o endereço de origem para os clientes se conectarem, para que nossos logs e outros módulos do IIS que dependem do endereço IP do cliente não precisem de modificação. Assim, os pacotes chegam falsificados como se tivessem vindo de um endereço IP externo da Internet, quando, na verdade, eles vinham de um IP local HAProxy 192.168.x.x em nossa rede local.

Ambos os servidores da Web têm duas NICs - um endereço de classe B roteável na Internet pública com um IP estático, DNS e gateway padrão e um endereço C de classe privada não rotuável configurado com um gateway padrão apontado no IP privado para HAProxy . O HAProxy possui duas interfaces - uma pública e uma privada e realiza o trabalho de roteamento de pacotes de forma transparente entre as interfaces e direcionar o tráfego para o servidor da Web apropriado.

Ethernet adapter Internet:

   Description . . . . . . . . . . . : network card #1
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 69.59.196.217 (Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Default Gateway . . . . . . . . . : 69.59.196.209
   DNS Servers . . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Private Local:

   Description . . . . . . . . . . . : network card #2
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.2 (Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.50
   NetBIOS over Tcpip. . . . . . . . : Enabled

Desativamos as métricas automáticas em cada um dos servidores da Web e atribuímos à classe pública roteável B uma métrica de 10 e nossa interface privada a uma métrica de 20.

Também definimos as duas chaves de registro:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableDeadGWDetect"=dword:00000000

Cerca de duas vezes por dia, vemos problemas em que um dos servidores da Web não pode entrar em contato com o DNS ou fazer conexões com outros servidores na Internet pública.

Suspeitamos que a detecção de gateways inativos esteja falsamente detectando uma indisponibilidade no gateway público e está trocando todo o tráfego para o gateway privado que não tem acesso a DNS neste momento, mas não tem como verificar isso.

1. Existe uma maneira de saber se a detecção de gateway inativo está em execução ou até mesmo uma opção no servidor Windows 2008?

2. Em caso afirmativo, existe uma maneira de desativar a detecção de gateways mortos no servidor Windows 2008?

3. Se não, poderia haver outros motivos pelos quais perdemos a capacidade de resolver DNS ou conectar-nos por um curto período de tempo?

Answer 1

Não conseguimos chegar a um resultado conclusivo do motivo pelo qual não conseguimos controlar o comportamento da Dead Gateway Detection.

Em vez de gastar muito tempo resolvendo esse problema, optamos por fazer com que a nossa instância HAProxy direcionasse o tráfego para a saída do gateway e definisse o gateway padrão dos servidores Web como o IP do haproxy e removesse o endereço do gateway interno.

  [ soweb1 ] 69.59.196.220, GW=69.59.196.211 [haproxy]
       |
       +---- [haproxy] 69.59.196.211, GW 69.59.196.209
       |
    [ gw ] 69.59.196.209

Agora há apenas um gateway padrão que elimina nosso problema porque a detecção de gateway padrão morto não é mais usada.

    

Answer 2

Essas DWORDs de Detecção de Gateway Morto são inúteis no Windows Server 2008. A única razão pela qual elas existem é por motivos de compatibilidade. O driver TCP / IP e os componentes do roteador do Windows não procuram mais esses valores.

Eu suspeito que esse recurso foi colocado no Auto-ajuste, que estreou no Windows Vista. Tente executar o seguinte em um prompt de comando elevado (e reinicializar):

netsh int tcp set global autotuninglevel=disabled

Update ( adicionado em 13 de setembro de 2009 @ 7: 58PM EST )

Se isso não funcionar, precisaremos de mais resultados de diagnóstico. Inicie um rastreamento (circular) com os cenários NetConnection ou LAN e deixe-o continuar em execução até que o problema ocorra.

netsh trace start scenario=NetConnection maxSize=512

_{(Exemplo: inicia o cenário de rastreamento NetConnection, com um tamanho máximo de log de rastreamento de 512 MB)}

Você pode abrir o rastreamento resultante em Network Monitor 3.3 , apenas certifique-se de instalar os analisadores mais recentes .

    

Answer 3

Eu questionaria por que você precisa mesmo alterar o gateway padrão para ser o HAproxy. Geralmente, você não deve alterar seu gateway padrão, a menos que esteja apontando para uma configuração N + 1 altamente disponível, em que o IP do gateway pode fazer failover para outro roteador / máquina no caso de algo ruim acontecer. Se algo acontecesse com sua máquina HAproxy e você não tivesse nenhum acesso fora de banda, então os servidores da web simplesmente cairiam da Internet.

Como acredito que a razão pela qual você pode estar fazendo isso é porque você está usando o Tproxy em sua configuração para fazer com que o endereço IP dos clientes apareça nos seus logs e não o IP do servidor proxy, sugiro que você faça isso

1. Adicione "option forwardfor ..." à sua configuração do HAproxy
2. Instale o filtro ISAPI encaminhado x para
3. Remover o tproxy da sua configuração
4. Altere o gateway padrão de volta para o mesmo gateway que você estava usando antes com conexão direta à internet

Eu não tenho uma máquina Windows para testar isso, mas acredito que deve resultar no efeito desejado sem a perda indesejada de conectividade.

    

Answer 4

Quando o acesso à Internet está envolvido (geralmente), os gateways padrão só devem ser usados para indicar um caminho para a INTERNET. Se você tiver vários gateways padrão definidos, o roteador do SO não poderá decidir qual deles usar, e se um gateway padrão apontar para um beco sem saída (por exemplo, sua LAN de múltiplos segmentos), os pacotes encaminhados para a Internet serão não vai fazer isso.