Erkennung eines toten Gateways unter Windows 2008 Server

9

Wir haben kürzlich HAProxy für stackoverflow.com implementiert. Wir haben uns für die Verwendung von TProxy entschieden, um die Quelladresse für Clients zu verwalten, die eine Verbindung herstellen, damit unsere Protokolle und andere IIS-Module, die von der Client-IP-Adresse abhängen, nicht geändert werden müssen. Die Pakete kommen also gefälscht an, als ob sie von einer externen Internet-IP-Adresse stammen, während sie in Wirklichkeit von einer lokalen 192.168.xx HAProxy-IP in unserem lokalen Netzwerk stammen.

Unsere beiden Webserver verfügen über zwei Netzwerkkarten - eine routingfähige Klasse-B-Adresse im öffentlichen Internet mit einer statischen IP-, DNS- und Standard-Gateway-Adresse und eine private nicht routbare Klasse-C-Adresse, die mit einem Standard-Gateway konfiguriert ist, das auf die private IP-Adresse für HAProxy verweist. HAProxy verfügt über zwei Schnittstellen - eine öffentliche und eine private - und leitet Pakete transparent zwischen Schnittstellen weiter und leitet den Datenverkehr an den entsprechenden Webserver weiter.

Ethernet-Adapter Internet:

   Beschreibung . . . . . . . . . . . : Netzwerkkarte Nr. 1
   DHCP aktiviert. . . . . . . . . . . : Nein
   Autokonfiguration aktiviert. . . . : Ja
   IPv4-Adresse. . . . . . . . . . . : 69.59.196.217 (bevorzugt)
   Subnetzmaske. . . . . . . . . . . : 255.255.255.240
   Standard-Gateway . . . . . . . . . : 69.59.196.209
   DNS-Server. . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS über Tcpip. . . . . . . . : Aktiviert

Ethernet-Adapter Private Local:

   Beschreibung . . . . . . . . . . . : Netzwerkkarte Nr. 2
   DHCP aktiviert. . . . . . . . . . . : Nein
   Autokonfiguration aktiviert. . . . : Ja
   IPv4-Adresse. . . . . . . . . . . : 192.168.0.2 (bevorzugt)
   Subnetzmaske. . . . . . . . . . . : 255.255.255.0
   Standard-Gateway . . . . . . . . . : 192.168.0.50
   NetBIOS über Tcpip. . . . . . . . : Aktiviert

Wir haben automatische Metriken auf jedem der Webserver deaktiviert und der routbaren öffentlichen Klasse B eine Metrik von 10 und unserer privaten Schnittstelle eine Metrik von 20 zugewiesen.

Wir haben auch beide Registrierungsschlüssel festgelegt:

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

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

Ungefähr zweimal pro Tag treten Probleme auf, bei denen einer der Webserver keinen Kontakt zu DNS herstellen oder keine Verbindung zu anderen Servern im öffentlichen Internet herstellen kann.

Wir vermuten, dass die Erkennung eines toten Gateways fälschlicherweise einen Ausfall des öffentlichen Gateways erkennt und den gesamten Datenverkehr auf das private Gateway umleitet, das zu diesem Zeitpunkt keinen DNS-Zugriff hat, dies jedoch nicht überprüfen kann.

Gibt es eine Möglichkeit, festzustellen, ob die Erkennung eines toten Gateways ausgeführt wird, oder sogar eine Option in Windows 2008 Server?
Wenn ja, gibt es eine Möglichkeit, die Erkennung toter Gateways auf einem Windows 2008-Server zu deaktivieren?
Wenn nicht, könnte es andere Gründe geben, warum wir die Fähigkeit verlieren, DNS aufzulösen oder für kurze Zeit eine Verbindung herzustellen?

— Geoff Dalgas
quelle

1

Obwohl dieses Setup manchmal verpönt ist (siehe blogs.technet.com/timmcmic/archive/2009/04/26/… ), funktioniert es für uns hervorragend - der gesamte Datenverkehr, der von HAProxy zu unseren IIS-Sites kommt, scheint immer noch von der zu kommen ursprüngliche IP-Adresse. Dies spart unermessliche Zeit, da wir IIS und seine unzähligen Plug-Ins konfigurieren müssten, um einen HTTP_X_FORWARDED_FOR-Header zu verwenden.

— Jarrod Dixon

1

Warum ist auf der 192.168.0.2-Schnittstelle ein Gateway konfiguriert? Sie können ein leeres Standard-Gateway konfigurieren (und tatsächlich fordert Windows Sie dazu auf, wenn Sie über zwei Schnittstellen verfügen).

— Portman

@Portman - Da in unseren Webboxen der Datenverkehr mit den ursprünglichen Client-IPs intakt ist, werden die Antworten nicht an unser Netzwerk gesendet. Deshalb müssen wir ein Standard-Gateway zu unserer HAProxy-Box haben.

— Jarrod Dixon

@ Jarrod - diese Konfiguration scheint verdächtig. Was ist, wenn Sie eine nicht ausgeglichene Website auf diesem Webserver ausführen möchten? Die Antwort wird über HAProxy weitergeleitet? Wie würden Sie mit so etwas wie Remotedesktop umgehen? Mir ist klar, dass dies die Frage nicht anspricht, aber dies scheint ein Fall von "Du machst es falsch" zu sein, was daivdsmalley (höflich) sagt.

— Portman

4

@ Jeff / Geoff / Jarrod - Ich hasse es, das Offensichtliche zu sagen, aber ihr seid Softwareentwickler. Warum nicht jemanden einstellen, der ein Spezialist für einen Tag ist, um das Problem zu beheben? Es ist alles sehr schön, sich die Hände schmutzig zu machen, aber hier gibt es eine deutliche Wissenslücke, die sich zeitweise auf das Geschäft auswirkt, und Sie haben eindeutig ein gutes Stück wertvoller Zeit damit verbracht, Ihre Kernkompetenzen, die Entwicklung, nicht zu nutzen. Vertrauen Sie mir, lassen Sie jemanden reparieren und wählen Sie dann sein Gehirn aus, nachdem Sie es zum Laufen gebracht haben. Zur Hölle, selbst als Webhoster müssen wir Leute dazu bringen, diese Lücken zu schließen, wenn es geschäftskritisch / dienstleistungsbeeinträchtigend ist.

— Kev

5

Diese DWORDs zur Erkennung toter Gateways sind unter Windows Server 2008 unbrauchbar. Der einzige Grund, warum sie existieren, ist aus Kompatibilitätsgründen. Der TCP / IP-Treiber und die Windows-Routerkomponenten suchen nicht mehr nach diesen Werten.

Ich vermute, dass diese Funktion in die automatische Optimierung integriert wurde, die unter Windows Vista eingeführt wurde. Versuchen Sie, Folgendes an einer Eingabeaufforderung mit erhöhten Rechten auszuführen (und neu zu starten):

netsh int tcp set global autotuninglevel = disabled

Update ( hinzugefügt am 13. September 2009 um 19:58 Uhr EST )

Wenn das nicht funktioniert, benötigen wir mehr Diagnoseausgabe. Starten Sie eine (zirkuläre) Ablaufverfolgung mit den NetConnection- oder LAN-Szenarien und lassen Sie sie weiterlaufen, bis das Problem auftritt.

Startszenario für Netsh-Trace = NetConnection maxSize = 512

_{(Beispiel: Startet das NetConnection-Ablaufverfolgungsszenario mit einer maximalen Größe des Ablaufverfolgungsprotokolls von 512 MB.)}

Sie können den resultierenden Trace in Network Monitor 3.3 öffnen. Stellen Sie lediglich sicher, dass Sie die neuesten Parser installieren .

— Rafael Rivera
quelle

Gute Idee, schien aber auch nicht zu funktionieren. Ich habe gerade einen 5-minütigen ausgehenden Verkehrsausfall erlebt - der sich auf mysteriöse Weise selbst behoben hat.

— Jeff Atwood

@ Jeff: Hmm, wir brauchen mehr Daten Captain! Siehe oben bearbeiten.

— Rafael Rivera

5

Wir konnten kein schlüssiges Ergebnis erzielen, warum wir das Verhalten der Dead Gateway Detection nicht kontrollieren konnten.

Anstatt viel Zeit mit der Behebung dieses Problems zu verbringen, haben wir uns dafür entschieden, dass unsere HAProxy-Instanz den Datenverkehr zum ausgehenden Gateway weiterleitet und das Standard-Gateway beider Webserver auf die IP-Adresse von haproxy setzt und die interne Gateway-Adresse entfernt.

  [ 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

Jetzt gibt es nur noch ein Standard-Gateway, wodurch unser Problem behoben wird, da die Erkennung eines toten Standard-Gateways nicht mehr verwendet wird.

— Geoff Dalgas
quelle

4

Ich würde fragen, warum Sie das Standard-Gateway überhaupt so ändern müssen, dass es überhaupt HAproxy ist. Im Allgemeinen sollten Sie Ihr Standard-Gateway überhaupt nicht ändern, es sei denn, Sie verweisen auf ein hochverfügbares N + 1-Setup, bei dem die Gateway-IP im Falle eines schlechten Ereignisses auf einen anderen Router / Computer umschalten kann. Wenn etwas mit Ihrem HAproxy-Computer passiert ist und Sie keinen Out-of-Band-Zugriff hatten, haben die Webserver einfach das Internet verlassen.

Da ich glaube, dass Sie dies möglicherweise tun, weil Sie Tproxy in Ihrem Setup verwenden, damit die IP-Adresse des Clients in Ihren Protokollen und nicht in der IP des Proxyservers angezeigt wird, kann ich vorschlagen, dass Sie dies stattdessen tun

Fügen Sie Ihrer HAproxy-Konfiguration "Option forwardfor ..." hinzu
Installieren Sie den x-forwarded-for ISAPI-Filter
Entfernen Sie tproxy aus Ihrem Setup
Ändern Sie das Standard-Gateway wieder in dasselbe Gateway, das Sie zuvor mit direkter Internetverbindung verwendet haben

Ich habe keinen Windows-Computer, auf dem ich dies testen kann, aber ich glaube, dass dies den gewünschten Effekt ohne den unerwünschten Verlust der Konnektivität erzielen sollte.

— Davidmalley
quelle

Ich habe gerade erst Ihren Kommentar zur ursprünglichen Frage zu diesem Setup gesehen. Ich würde jedoch bezweifeln, dass "es für uns hervorragend funktioniert", wenn Ihre Server die Internetverbindung verlieren :)

— Davidmalley

3

Alternativ können Sie sich eine viel robustere Lösung wie ldirectord + heartbeat ansehen, die nur den Datenverkehr auf Kernelebene umleitet, da überhaupt kein Proxy erforderlich ist. Ich benutze dieses Setup ausgiebig und es funktioniert großartig. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html

— davidsmalley

Wir haben uns die Verwendung dieses x-forwarded-forHeaders und der IIS-Filter zum Ändern der Protokolle angesehen, wissen jedoch nicht, wie (oder ob) unsere anderen optionalen IIS-Module den Header ebenfalls in ihrem Betrieb verwenden.

— Jarrod Dixon

Vielen Dank für diesen Link zu linuxvirtualserver.org/HighAvailability.html - die Informationen dort sind unglaublich! Ich bin in diesen Themen absolut unwissend (weshalb ich nicht derjenige bin, der das alles vorbereitet!), Aber ich versuche so schnell wie möglich zu lernen. Vielleicht können wir Herzschlag + ldirectord ähnlich bedienen wie linuxvirtualserver.org/docs/ha/ultramonkey.html tut es mit unseren Lieblingen HAProxy.

— Jarrod Dixon

-1

Wenn der Internetzugang (normalerweise) betroffen ist, sollten Standard-Gateways NIEMALS verwendet werden, um einen Pfad zum INTERNET anzugeben. Wenn Sie mehrere Standardgateways definiert haben, kann der Betriebssystemrouter nicht entscheiden, welches verwendet werden soll. Wenn ein Standardgateway auf eine Sackgasse (z. B. Ihr Multisegment-LAN) verweist, sind die dort für das Internet weitergeleiteten Pakete werde es nicht schaffen.

— Adrien
quelle