Detecção de gateway inoperante no Windows 2008 Server

Implementamos recentemente o HAProxy para stackoverflow.com. Decidimos usar o TProxy para manter o endereço de origem dos clientes conectados, para que nossos logs e outros módulos do IIS que dependem do endereço IP do cliente não precisem de modificação. Portanto, os pacotes chegam falsificados como se tivessem vindo de um endereço IP externo da Internet, quando na realidade vieram de um IP HAProxy 192.168.xx local 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 de classe C privado irrecuperável configurado com um gateway padrão apontado para o IP privado do HAProxy. O HAProxy possui duas interfaces - uma pública e outra privada e executa o trabalho de rotear pacotes de forma transparente entre as interfaces e direcionar o tráfego para o servidor da web apropriado.

Adaptador Ethernet Internet:

   Descrição . . . . . . . . . . . : placa de rede # 1
   DHCP ativado. . . . . . . . . . . : Não
   Configuração automática ativada. . . . : Sim
   Endereço IPv4. . . . . . . . . . . : 69.59.196.217 (Preferencial)
   Máscara de sub-rede. . . . . . . . . . . : 255.255.255.240
   Gateway padrão. . . . . . . . . : 69.59.196.209
   Servidores DNS. . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS sobre Tcpip. . . . . . . . : Ativado

Local Ethernet privado do adaptador Ethernet:

   Descrição . . . . . . . . . . . : placa de rede # 2
   DHCP ativado. . . . . . . . . . . : Não
   Configuração automática ativada. . . . : Sim
   Endereço IPv4. . . . . . . . . . . : 192.168.0.2 (Preferencial)
   Máscara de sub-rede. . . . . . . . . . . : 255.255.255.0
   Gateway padrão. . . . . . . . . : 192.168.0.50
   NetBIOS sobre Tcpip. . . . . . . . : Ativado

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

Também definimos essas duas chaves do 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 gateway morto esteja detectando falsamente uma interrupção no gateway público e esteja alternando todo o tráfego para o gateway privado que não tem acesso ao DNS neste momento, mas não tem como verificar isso.

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

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

3. Caso contrário, pode haver outros motivos pelos quais perdemos a capacidade de resolver o DNS ou conectar-se por um curto período de tempo?

Esses DWORDs de detecção de gateway morto são inúteis no Windows Server 2008. A única razão pela qual eles existem é por motivos de compatibilidade. O driver TCP / IP e os componentes do roteador do Windows não procuram mais esses valores.

Suspeito que esse recurso tenha sido lançado no Autoajuste, lançado no Windows Vista. Tente executar o seguinte em um prompt de comando elevado (e reinicie):

netsh int tcp set global autotuninglevel = desativado

Atualização ( adicionada 13 de setembro de 2009 às 19: 58PM EST )

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

cenário de início do rastreamento netsh = 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 no Network Monitor 3.3 , apenas certifique-se de instalar os analisadores mais recentes .

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 solucionando esse problema, optamos por fazer com que nossa instância HAProxy roteie o tráfego para a saída do gateway e defina o gateway padrão de ambos os servidores da Web para o IP do haproxy e removemos o endereço interno do gateway.

  [ 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, existe apenas um gateway padrão que elimina nosso problema porque a detecção de gateway padrão morto não é mais usada.

Gostaria de perguntar por que você ainda precisa alterar o gateway padrão para ser 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 possa executar failover para outro roteador / máquina no caso de algo ruim acontecer. Se algo acontecesse com a sua máquina HAproxy e você não tivesse acesso fora de banda, os servidores da Web simplesmente deixariam a Internet.

Como acredito que o motivo para você estar fazendo isso, é porque você está usando o Tproxy em sua instalação para fazer com que o endereço IP do cliente apareça nos seus logs e não no IP do servidor proxy. Posso sugerir que você faça isso

1. Adicione "opção forwardfor ..." à sua configuração do HAproxy
2. Instale o filtro ISAPI encaminhado por x
3. Remova o tproxy da sua configuração
4. Mude o gateway padrão de volta para o mesmo gateway usado antes com conexão direta à Internet

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

Quando o acesso à Internet está envolvido (normalmente), os gateways padrão devem sempre ser usados ​​para indicar o caminho para a INTERNET. Se você tiver vários gateways padrão definidos, o roteador do SO não poderá decidir qual usar e se um gateway padrão apontar para um beco sem saída (por exemplo, sua LAN com vários segmentos), os pacotes encaminhados para a Internet serão não vai conseguir.