Détection de passerelle morte sur Windows 2008 Server

9

Nous avons récemment implémenté HAProxy pour stackoverflow.com. Nous avons décidé d'utiliser TProxy pour maintenir l'adresse source des clients se connectant afin que nos journaux et autres modules IIS qui dépendent de l'adresse IP du client n'aient pas besoin d'être modifiés. Ainsi, les paquets arrivent usurpés comme s'ils venaient d'une adresse IP Internet externe, alors qu'en réalité ils provenaient d'une IP HAProxy 192.168.xx locale sur notre réseau local.

Nos deux serveurs Web ont deux NIC - une adresse routable de classe B sur Internet public avec une adresse IP statique, DNS et une passerelle par défaut et une adresse privée de classe C non routable configurée avec une passerelle par défaut pointée vers l'IP privée pour HAProxy. HAProxy a deux interfaces - une publique et une privée et effectue le travail de routage transparent des paquets entre les interfaces et de diriger le trafic vers le serveur Web approprié.

Adaptateur Ethernet Internet:

   La description . . . . . . . . . . . : carte réseau # 1
   DHCP activé. . . . . . . . . . . : Non
   Autoconfiguration activée. . . . : Oui
   Adresse IPv4. . . . . . . . . . . : 69.59.196.217 (préféré)
   Masque de sous-réseau. . . . . . . . . . . : 255.255.255.240
   Passerelle par défaut. . . . . . . . . : 69.59.196.209
   Serveurs DNS. . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS sur Tcpip. . . . . . . . : Activée

Adaptateur Ethernet Private Local:

   La description . . . . . . . . . . . : carte réseau # 2
   DHCP activé. . . . . . . . . . . : Non
   Autoconfiguration activée. . . . : Oui
   Adresse IPv4. . . . . . . . . . . : 192.168.0.2 (préféré)
   Masque de sous-réseau. . . . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : 192.168.0.50
   NetBIOS sur Tcpip. . . . . . . . : Activée

Nous avons désactivé les métriques automatiques sur chacun des serveurs Web et attribué à la classe publique routable B une métrique de 10 et notre interface privée une métrique de 20.

Nous avons également défini ces deux clés de registre:

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

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

Environ deux fois par jour, nous constatons des problèmes où l'un des serveurs Web ne peut pas contacter le DNS ou établir des connexions avec d'autres serveurs sur Internet public.

Nous pensons que la détection de passerelle morte détecte à tort une panne sur la passerelle publique et commute tout le trafic vers la passerelle privée qui n'a pas d'accès DNS à ce stade mais n'a aucun moyen de le vérifier.

  1. Existe-t-il un moyen de savoir si la détection de passerelle morte est en cours d'exécution ou même une option dans le serveur Windows 2008?

  2. Si oui, existe-t-il un moyen de désactiver la détection de passerelle morte dans le serveur Windows 2008?

  3. Sinon, pourrait-il y avoir d'autres raisons pour lesquelles nous perdons la capacité de résoudre le DNS ou de nous déconnecter pendant une courte période?

windows-server-2008 networking tcpip haproxy Geoff Dalgas
la source
1
Bien que cette configuration soit parfois mal vue (voir blogs.technet.com/timmcmic/archive/2009/04/26/… ), elle fonctionne énormément pour nous - tout le trafic provenant de HAProxy vers nos sites IIS semble provenir toujours de la adresse IP d'origine. Cela permet d'économiser un temps incalculable, car il faudrait (savoir comment) configurer IIS et ses innombrables plug-ins pour utiliser un en-tête HTTP_X_FORWARDED_FOR.
Jarrod Dixon
1
Pourquoi avez-vous une passerelle configurée sur l'interface 192.168.0.2? Vous pouvez configurer une passerelle par défaut vide (et en fait, c'est ce que Windows vous invite à faire lorsque vous avez deux interfaces).
Portman
@Portman - parce que nos boîtes Web voient le trafic avec les adresses IP des clients d'origine intactes, les réponses ne seront pas envoyées à notre réseau - c'est pourquoi nous devons avoir une passerelle par défaut vers notre boîte HAProxy.
Jarrod Dixon
@Jarrod - cette configuration semble suspecte. Et si vous souhaitez exécuter un site Web non équilibré sur ce serveur Web? La réponse sera acheminée via HAProxy? Comment géreriez-vous quelque chose comme un bureau à distance? Je me rends compte que cela ne règle pas la question, mais cela ressemble à un cas où vous le faites mal, c'est ce que daivdsmalley dit (poliment).
Portman
4
@ Jeff / Geoff / Jarrod - Je déteste dire l'évidence, mais vous êtes des développeurs de logiciels, pourquoi ne pas embaucher quelqu'un qui est un spécialiste pour une journée à corriger? C'est très agréable de se salir les mains, mais il y a clairement un manque de connaissances ici, cela affecte par intermittence l'entreprise et vous avez clairement passé un bon bout de temps précieux à ne pas utiliser vos compétences de base qui sont le développement. Faites-moi confiance, demandez à quelqu'un de réparer, puis choisissez son cerveau après l'avoir fait fonctionner. Enfer, même en tant qu'hébergeurs de sites Web, nous devons faire appel à des gens pour combler ces lacunes lorsque cela est critique pour la mission / le service.
Kev

Réponses:

5

Ces DWORD de détection de passerelle morte sont inutiles sur Windows Server 2008. La seule raison pour laquelle ils existent est pour des raisons de compatibilité. Le pilote TCP / IP et les composants du routeur Windows ne recherchent plus ces valeurs.

Je soupçonne que cette fonctionnalité a été intégrée dans le réglage automatique, qui a fait ses débuts dans Windows Vista. Essayez d'exécuter ce qui suit dans une invite de commande élevée (et redémarrez):

netsh int tcp set global autotuninglevel = désactivé


Mise à jour ( ajoutée le 13 septembre 2009 à 19 h 58 HNE )

Si cela ne fonctionne pas, nous aurons besoin de plus de résultats de diagnostic. Démarrez une trace (circulaire) avec les scénarios NetConnection ou LAN et laissez-la continuer à fonctionner jusqu'à ce que le problème se produise.

scénario de démarrage de la trace netsh = NetConnection maxSize = 512

(Exemple: démarre le scénario de suivi NetConnection, avec une taille maximale de journal de suivi de 512 Mo)

Vous pouvez ouvrir la trace résultante dans le Moniteur réseau 3.3 , assurez-vous simplement d'installer les derniers analyseurs .

Rafael Rivera
la source
bonne idée, mais ne semble pas fonctionner non plus .. vient de subir une panne de trafic sortant de 5 minutes - qui s'est mystérieusement corrigé.
Jeff Atwood
@Jeff: Hmm, nous avons besoin de plus de données Capitaine! Voir modification ci-dessus.
Rafael Rivera
5

Nous n'avons pas pu arriver à un résultat concluant quant à la raison pour laquelle nous ne pouvions pas contrôler le comportement de la détection de passerelle morte.

Plutôt que de passer une tonne de temps à résoudre ce problème, nous avons choisi de faire en sorte que notre instance HAProxy achemine le trafic vers la passerelle sortante et définisse la passerelle par défaut des deux serveurs Web sur l'IP de haproxy et a supprimé l'adresse de passerelle interne. 

  [ 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

Maintenant, il n'y a qu'une seule passerelle par défaut qui élimine notre problème car la détection de passerelle par défaut morte n'est plus utilisée.

Geoff Dalgas
la source
4

Je me demande pourquoi vous devez même changer la passerelle par défaut pour être HAproxy. En règle générale, vous ne devez pas modifier votre passerelle par défaut, sauf si vous la pointez vers une configuration N + 1 hautement disponible où l'IP de la passerelle peut basculer vers un autre routeur / machine en cas de problème. Si quelque chose arrivait à votre machine HAproxy et que vous n'aviez aucun accès hors bande, les serveurs Web abandonneraient simplement Internet.

Comme je pense que la raison pour laquelle vous le faites est parce que vous utilisez Tproxy dans votre configuration pour faire apparaître l'adresse IP des clients dans vos journaux et non l'IP du serveur proxy, puis-je vous suggérer de le faire à la place

  1. Ajoutez "option forwardfor ..." à votre configuration HAproxy
  2. Installer le filtre ISAPI x-forwarded-for
  3. Supprimer tproxy de votre configuration
  4. Remplacez la passerelle par défaut par la même passerelle que vous utilisiez auparavant avec une connexion directe à Internet

Je n'ai pas de machine Windows pour tester cela, mais je pense que cela devrait produire l'effet souhaité sans perte de connectivité indésirable.

davidsmalley
la source
Je viens de repérer votre commentaire sur la question d'origine concernant cette configuration. Cependant, je douterais que "cela fonctionne énormément pour nous" si vos serveurs
perdent la
3
Alternativement, vous pouvez envisager une solution beaucoup plus robuste telle que ldirectord + heartbeat qui redirige simplement le trafic au niveau du noyau, en tant que tel, aucun mandataire n'est impliqué du tout. J'utilise largement cette configuration et cela fonctionne très bien. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html
davidsmalley
Nous avons envisagé d'utiliser cet en- x-forwarded-fortête et les filtres IIS pour modifier les journaux, mais nous ne savons pas comment (ou si) nos autres modules IIS facultatifs utilisent également l'en-tête dans leur fonctionnement.
Jarrod Dixon
Merci pour ce lien linuxvirtualserver.org/HighAvailability.html - les informations y sont incroyables! Je suis au-delà de l'ignorance sur ces sujets (c'est pourquoi je ne suis pas le seul à mettre tout cela en place!), Mais j'essaie d'apprendre le plus vite possible. Nous pouvons peut-être utiliser heartbeat + ldirectord de la même manière que linuxvirtualserver.org/docs/ha/ultramonkey.html le fait avec notre HAProxy préféré.
Jarrod Dixon
-1

Lorsque l'accès à Internet est impliqué (généralement), les passerelles par défaut ne doivent être utilisées que pour indiquer un chemin d'accès à INTERNET. Si vous avez défini plusieurs passerelles par défaut, le routeur du système d'exploitation ne peut pas décider laquelle utiliser, et si une passerelle par défaut pointe vers un cul-de-sac (par exemple, votre réseau local multisegment), les paquets qui y sont transmis pour Internet sont ne va pas le faire.

Adrien
la source