Detección de puerta de enlace muerta en Windows 2008 Server

9

Recientemente hemos implementado HAProxy para stackoverflow.com. Decidimos usar TProxy para mantener la dirección de origen de los clientes que se conectan para que nuestros registros y otros módulos IIS que dependen de la dirección IP del cliente no requieran modificación. Entonces, los paquetes llegan falsificados como si vinieran de una dirección IP externa de Internet, cuando en realidad provienen de una IP local HAProxy 192.168.xx en nuestra red local.

Nuestros dos servidores web tienen dos NIC: una dirección de clase B enrutable en Internet pública con una IP estática, DNS y una puerta de enlace predeterminada y una dirección de clase C privada no enrutable configurada con una puerta de enlace predeterminada apuntada a la IP privada para HAProxy. HAProxy tiene dos interfaces: una pública y otra privada, y realiza el trabajo de enrutar paquetes de forma transparente entre las interfaces y dirigir el tráfico al servidor web apropiado.

Adaptador Ethernet Internet:

   Descripción . . . . . . . . . . : tarjeta de red # 1
   DHCP habilitado. . . . . . . . . . . : No
   Autoconfiguración habilitada. . . . : Si
   Dirección IPv4 . . . . . . . . . . : 69.59.196.217 (Preferido)
   Máscara de subred . . . . . . . . . . . : 255.255.255.240
   Puerta de enlace predeterminada . . . . . . . . . : 69.59.196.209
   Servidores DNS . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS sobre Tcpip. . . . . . . . : Habilitado

Adaptador Ethernet Privado Local:

   Descripción . . . . . . . . . . : tarjeta de red # 2
   DHCP habilitado. . . . . . . . . . . : No
   Autoconfiguración habilitada. . . . : Si
   Dirección IPv4 . . . . . . . . . . : 192.168.0.2 (Preferido)
   Máscara de subred . . . . . . . . . . . : 255.255.255.0
   Puerta de enlace predeterminada . . . . . . . . . : 192.168.0.50
   NetBIOS sobre Tcpip. . . . . . . . : Habilitado

Hemos deshabilitado las métricas automáticas en cada uno de los servidores web y hemos asignado a la clase pública enrutable B una métrica de 10 y nuestra interfaz privada una métrica de 20.

También hemos establecido estas dos claves de registro:

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

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

Aproximadamente dos veces al día vemos problemas en los que uno de los servidores web no puede contactar a DNS o establecer conexiones con otros servidores en Internet público.

Sospechamos que la detección de puerta de enlace muerta está detectando falsamente una interrupción en la puerta de enlace pública y está cambiando todo el tráfico a la puerta de enlace privada que no tiene acceso a DNS en este momento, pero no tiene forma de verificarlo.

  1. ¿Hay alguna manera de saber si se está ejecutando la detección de puerta de enlace muerta o incluso una opción en el servidor de Windows 2008?

  2. Si es así, ¿hay alguna forma de deshabilitar la detección de puerta de enlace muerta en el servidor de Windows 2008?

  3. Si no, ¿podría haber otras razones por las que perdemos la capacidad de resolver DNS o conectarnos por un corto tiempo?

windows-server-2008 networking tcpip haproxy Geoff Dalgas
fuente
1
Si bien esta configuración a veces está mal vista (ver blogs.technet.com/timmcmic/archive/2009/04/26/… ), funciona de maravilla para nosotros: todo el tráfico que viene de HAProxy a nuestros sitios IIS parece que todavía proviene del dirección IP original Esto ahorra una gran cantidad de tiempo, ya que tendríamos que (averiguar cómo) configurar IIS y sus innumerables complementos para usar un encabezado HTTP_X_FORWARDED_FOR.
Jarrod Dixon
1
¿Por qué tiene una puerta de enlace configurada en la interfaz 192.168.0.2? Puede configurar una puerta de enlace predeterminada vacía (y, de hecho, esto es lo que Windows le pide que haga cuando tiene dos interfaces).
Portman el
@Portman: debido a que nuestros cuadros web están viendo el tráfico con las IP del cliente de origen intactas, las respuestas no se enviarán a nuestra red; es por eso que tenemos que tener una puerta de enlace predeterminada a nuestro cuadro HAProxy.
Jarrod Dixon
@Jarrod: esa configuración parece sospechosa. ¿Qué pasa si desea ejecutar un sitio web no equilibrado en ese servidor web? La respuesta se enrutará a través de HAProxy? ¿Cómo manejarías algo como el escritorio remoto? Me doy cuenta de que esto no responde a la pregunta, pero parece un caso de Estás haciendo mal, que es lo que dice daivdsmalley (cortésmente).
Portman el
44
@ Jeff / Geoff / Jarrod - Odio decir lo obvio, pero ustedes son desarrolladores de software, ¿por qué no contratan a alguien que sea especialista por un día para arreglarlo? Es muy agradable ensuciarse las manos, pero hay una clara brecha de conocimiento aquí, está afectando intermitentemente al negocio y claramente ha pasado un poco de tiempo valioso sin utilizar sus habilidades básicas, que es el desarrollo. Confía en mí, pídele a alguien que lo arregle y luego elige su cerebro después de que lo hayas hecho funcionar. Demonios, incluso como webhosters necesitamos atraer a la gente para cerrar estas brechas cuando se trata de misión crítica / servicio.
Kev

Respuestas:

5

Esos DWORD de detección de puerta de enlace inactiva son inútiles en Windows Server 2008. La única razón por la que existen es por razones de compatibilidad. El controlador TCP / IP y los componentes del enrutador de Windows ya no buscan estos valores.

Sospecho que esta característica se incluyó en Auto-Tuning, que debutó en Windows Vista. Intente ejecutar lo siguiente en un símbolo del sistema elevado (y reinicie):

netsh int tcp set global autotuninglevel = disabled


Actualización ( agregado el 13 de septiembre de 2009 a las 7:58 p.m. EST )

Si eso no funciona, necesitaremos más resultados de diagnóstico. Inicie un rastreo (circular) con los escenarios de NetConnection o LAN y deje que continúe ejecutándose hasta que ocurra el problema.

escenario de inicio de seguimiento de netsh = NetConnection maxSize = 512

(Ejemplo: inicia el escenario de seguimiento de NetConnection, con un tamaño máximo de registro de seguimiento de 512 MB)

Puede abrir el seguimiento resultante en Network Monitor 3.3 , solo asegúrese de instalar los últimos analizadores .

Rafael Rivera
fuente
buena idea, pero tampoco parecía funcionar ... solo experimenté un corte de tráfico saliente de 5 minutos, que misteriosamente se arregló.
Jeff Atwood
@ Jeff: Hmm, ¡necesitamos más datos Capitán! Ver edición arriba.
Rafael Rivera
5

No pudimos llegar a un resultado concluyente de por qué no pudimos controlar el comportamiento de Dead Gateway Detection.

En lugar de perder un montón de tiempo resolviendo este problema, optamos por hacer que nuestra instancia de HAProxy enrute el tráfico hacia la puerta de enlace saliente y establezca la puerta de enlace predeterminada de ambos servidores web en la IP de haproxy y eliminemos la dirección de la puerta de enlace interna. 

  [ 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

Ahora solo hay una puerta de enlace predeterminada que elimina nuestro problema porque la detección de puerta de enlace predeterminada muerta ya no se usa.

Geoff Dalgas
fuente
4

Me preguntaría por qué incluso necesita cambiar la puerta de enlace predeterminada para que sea HAproxy. En general, no debe cambiar su puerta de enlace predeterminada a menos que esté apuntando a una configuración N + 1 de alta disponibilidad donde la IP de la puerta de enlace puede conmutar por error a otro enrutador / máquina en caso de que ocurra algo malo. Si algo le sucediera a su máquina HAproxy y usted no tuviera acceso fuera de banda, entonces los servidores web simplemente abandonarían Internet.

Como creo que la razón por la que puede estar haciendo esto es porque está utilizando Tproxy en su configuración para que la dirección IP del cliente aparezca en sus registros y no la IP del servidor proxy, ¿podría sugerirle que haga esto?

  1. Agregue "option forwardfor ..." a su configuración HAproxy
  2. Instale el filtro x-reenviado-para ISAPI
  3. Eliminar tproxy de tu configuración
  4. Vuelva a cambiar la puerta de enlace predeterminada a la misma puerta de enlace que estaba usando antes con conexión directa a Internet

No tengo una máquina Windows para probar esto, pero creo que debería dar como resultado el efecto deseado sin la pérdida no deseada de conectividad.

davidsmalley
fuente
Acabo de ver tu comentario sobre la pregunta original sobre esta configuración. Sin embargo, pongo en duda "funciona asombrosamente para nosotros" si sus servidores están perdiendo la conectividad a Internet :)
davidsmalley
3
Alternativamente, podría buscar una solución mucho más robusta, como ldirectord + heartbeat, que simplemente redirige el tráfico a nivel del kernel, por lo que no hay ningún proxy involucrado en absoluto. Uso esta configuración ampliamente y funciona muy bien. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html
davidsmalley
Hemos analizado el uso de ese x-forwarded-forencabezado y los filtros IIS para alterar los registros, pero no sabemos cómo (o si) nuestros otros módulos opcionales de IIS también usan el encabezado en su operación.
Jarrod Dixon
Gracias por ese enlace linuxvirtualserver.org/HighAvailability.html : ¡la información allí es increíble! Soy más que ignorante en estos temas (¡por eso no soy yo quien prepara todo esto!), Pero estoy tratando de aprender lo más rápido posible. Quizás podamos usar heartbeat + ldirectord de forma similar a como linuxvirtualserver.org/docs/ha/ultramonkey.html lo hace con nuestro HAProxy favorito.
Jarrod Dixon
-1

Cuando el acceso a Internet está involucrado (por lo general), las puertas de enlace predeterminadas solo deberían usarse NUNCA para indicar una ruta a INTERNET. Si tiene varias puertas de enlace predeterminadas definidas, el enrutador del sistema operativo no puede decidir cuál usar, y si una puerta de enlace predeterminada señala un callejón sin salida (por ejemplo, su LAN de múltiples segmentos), entonces los paquetes enviados allí para Internet son No lo voy a lograr.

Adrien
fuente