Rilevamento gateway morto su Windows 2008 Server

9

Recentemente abbiamo implementato HAProxy per stackoverflow.com. Abbiamo deciso di utilizzare TProxy per mantenere l'indirizzo di origine per i client che si connettono in modo che i nostri registri e altri moduli IIS che dipendono dall'indirizzo IP del client non richiedano modifiche. Quindi i pacchetti arrivano falsificati come se provenissero da un indirizzo IP Internet esterno, quando in realtà provenivano da un IP HAProxy 192.168.xx locale sulla nostra rete locale.

Entrambi i nostri server Web hanno due schede NIC: un indirizzo di classe B instradabile su Internet pubblico con un IP statico, DNS e gateway predefinito e un indirizzo di classe C non instradabile privato configurato con un gateway predefinito puntato sull'IP privato per HAProxy. HAProxy ha due interfacce: una pubblica e una privata e svolge il compito di instradare i pacchetti in modo trasparente tra le interfacce e indirizzare il traffico al server Web appropriato.

Adattatore Ethernet Internet:

   Descrizione . . . . . . . . . . : scheda di rete n. 1
   DHCP abilitato. . . . . . . . . . . : No
   Configurazione automatica abilitata. . . . : Sì
   Indirizzo IPv4. . . . . . . . . . . : 69.59.196.217 (preferito)
   Maschera di sottorete . . . . . . . . . . . : 255.255.255.240
   Gateway predefinito . . . . . . . . . : 69.59.196.209
   Server DNS. . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS su Tcpip. . . . . . . . : Abilitato

Adattatore Ethernet locale privato:

   Descrizione . . . . . . . . . . : scheda di rete n. 2
   DHCP abilitato. . . . . . . . . . . : No
   Configurazione automatica abilitata. . . . : Sì
   Indirizzo IPv4. . . . . . . . . . . : 192.168.0.2 (preferito)
   Maschera di sottorete . . . . . . . . . . . : 255.255.255.0
   Gateway predefinito . . . . . . . . . : 192.168.0.50
   NetBIOS su Tcpip. . . . . . . . : Abilitato

Abbiamo disabilitato le metriche automatiche su ciascuno dei server Web e assegnato alla classe pubblica instradabile B una metrica di 10 e la nostra interfaccia privata una metrica di 20.

Abbiamo anche impostato entrambe queste chiavi di registro:

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

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

Circa due volte al giorno vediamo problemi in cui uno dei server Web non è in grado di contattare DNS o stabilire connessioni con altri server su Internet pubblico.

Sospettiamo che il rilevamento di dead gateway stia rilevando erroneamente un'interruzione sul gateway pubblico e sta trasferendo tutto il traffico al gateway privato che non ha accesso DNS a questo punto ma non ha modo di verificarlo.

C'è un modo per sapere se è in esecuzione il rilevamento dead gateway o addirittura un'opzione nel server Windows 2008?
In tal caso, esiste un modo per disabilitare il rilevamento di dead gateway nel server Windows 2008?
In caso contrario, potrebbero esserci altri motivi per cui perdiamo la capacità di risolvere DNS o disconnetterci per un breve periodo?

— Geoff Dalgas
fonte

1

Mentre questa configurazione è talvolta disapprovata (vedi blogs.technet.com/timmcmic/archive/2009/04/26/… ), funziona in modo straordinario per noi - tutto il traffico proveniente da HAProxy verso i nostri siti IIS sembra che provenga ancora dal indirizzo IP originale. Ciò consente di risparmiare innumerevoli quantità di tempo, poiché dovremmo (scoprire come) configurare IIS e i suoi innumerevoli plug-in per utilizzare un'intestazione HTTP_X_FORWARDED_FOR.

— Jarrod Dixon

1

Perché hai un gateway configurato sull'interfaccia 192.168.0.2? Puoi configurare un gateway predefinito vuoto (e in effetti questo è ciò che Windows ti chiede di fare quando hai due interfacce).

— Portman,

@Portman - poiché le nostre caselle Web vedono intatto il traffico con gli IP dei client di origine, le risposte non verranno inviate alla nostra rete - ecco perché dobbiamo avere un gateway predefinito per la nostra casella HAProxy.

— Jarrod Dixon

@Jarrod - quella configurazione sembra sospetta. Che cosa succede se si desidera eseguire un sito Web non bilanciato su quel server Web? La risposta verrà instradata tramite HAProxy? Come gestiresti qualcosa come il desktop remoto? Mi rendo conto che questo non affronta la domanda, ma questo sembra un caso di Stai facendo male, che è ciò che Daivdsmalley sta dicendo (educatamente).

— Portman,

4

@ Jeff / Geoff / Jarrod - Odio affermare l'ovvio, ma voi ragazzi siete sviluppatori di software, perché non assumere qualcuno che è uno specialista per un giorno da risolvere? È tutto molto bello sporcarsi le mani, ma c'è un chiaro divario di conoscenza qui, sta influenzando in modo intermittente il business e hai chiaramente trascorso un bel po 'di tempo prezioso senza utilizzare le tue competenze chiave che sono lo sviluppo. Fidati di me, chiedi a qualcuno di aggiustarlo e poi scegli il suo cervello dopo averlo fatto funzionare. Inferno, anche come webhoster abbiamo bisogno di coinvolgere la gente per colmare queste lacune quando la missione / servizio influisce.

— Kev,

5

Quei DWORD di Dead Gateway Detection sono inutili su Windows Server 2008. L'unica ragione per cui esistono è per motivi di compatibilità. Il driver TCP / IP e i componenti del router di Windows non cercano più questi valori.

Sospetto che questa funzione sia stata implementata in Auto-Tuning, che ha debuttato in Windows Vista. Prova a eseguire quanto segue in un prompt dei comandi con privilegi elevati (e riavvia):

netsh int tcp set global autotuninglevel = disabilitato

Aggiornamento ( aggiunto il 13 settembre 2009 alle 7:58:00 EST )

Se non funziona, avremo bisogno di più output diagnostici. Avviare una traccia (circolare) con gli scenari NetConnection o LAN e lasciarlo continuare fino a quando si verifica il problema.

netsh trace start scenario = NetConnection maxSize = 512

_{(Esempio: avvia lo scenario di traccia NetConnection, con una dimensione massima del registro di traccia di 512 MB)}

Puoi aprire la traccia risultante in Network Monitor 3.3 , assicurati solo di installare gli ultimi parser .

— Rafael Rivera
fonte

buona idea, ma non sembra funzionare neanche .. ho appena subito un'interruzione del traffico in uscita di 5 minuti - che si è risolto misteriosamente.

— Jeff Atwood,

@Jeff: Hmm, abbiamo bisogno di più dati Capitano! Vedi modifica sopra.

— Rafael Rivera,

5

Non siamo riusciti a ottenere un risultato conclusivo sul perché non siamo riusciti a controllare il comportamento di Dead Gateway Detection.

Invece di dedicare un sacco di tempo alla risoluzione di questo problema, abbiamo deciso di instradare il traffico dell'istanza HAProxy verso il gateway in uscita e impostare il gateway predefinito di entrambi i server Web sull'IP del haproxy e rimuovere l'indirizzo del 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

Ora c'è solo un gateway predefinito che elimina il nostro problema perché il rilevamento del gateway predefinito morto non viene più utilizzato.

— Geoff Dalgas
fonte

4

Vorrei chiederti perché hai persino bisogno di cambiare il gateway predefinito in modo che sia HAproxy. Generalmente non è necessario modificare affatto il gateway predefinito a meno che non lo si indichi a un'installazione N + 1 a disponibilità elevata in cui l'IP del gateway può eseguire il failover su un altro router / computer in caso di problemi. Se accadesse qualcosa alla tua macchina HAproxy e non avessi accesso fuori banda, i server web abbandonerebbero Internet.

Poiché credo che il motivo per cui potresti farlo sia perché stai usando Tproxy nella tua configurazione per far apparire l'indirizzo IP dei client nei tuoi registri e non l'IP del server proxy, potrei suggerire di farlo invece

Aggiungi "opzione forwardfor ..." alla tua configurazione HAproxy
Installa il filtro ISAPI x-forwarded-for
Rimuovi tproxy dalla tua configurazione
Riporta il gateway predefinito allo stesso gateway che stavi utilizzando prima con la connessione diretta a Internet

Non ho un computer Windows su cui testarlo ma credo che dovrebbe comportare l'effetto desiderato senza la perdita indesiderata di connettività.

— davidsmalley
fonte

Ho appena notato il tuo commento sulla domanda originale relativa a questa configurazione. Tuttavia, dubiterei che "funziona in modo straordinario per noi" se i tuoi server perdono la connettività Internet :)

— davidsmalley,

3

In alternativa, potresti cercare una soluzione molto più solida come ldirectord + heartbeat che reindirizza il traffico a livello di kernel, in quanto tale non comporta alcun proxy. Uso ampiamente questa configurazione e funziona benissimo. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html

— davidsmalley,

Abbiamo esaminato l'utilizzo di quell'intestazione x-forwarded-fore dei filtri IIS per modificare i log, ma non sappiamo come (o se) anche i nostri altri moduli IIS opzionali utilizzino l'intestazione nelle loro operazioni.

— Jarrod Dixon

Grazie per quel link linuxvirtualserver.org/HighAvailability.html - le informazioni sono incredibili! Sono al di là dell'ignoranza su questi argomenti (motivo per cui non sono io a impostare tutto questo!), Ma sto cercando di imparare il più velocemente possibile. Forse possiamo usare heartbeat + ldirectord in modo simile a come linuxvirtualserver.org/docs/ha/ultramonkey.html lo fa con il nostro HAProxy preferito.

— Jarrod Dixon

-1

Quando è coinvolto l'accesso a Internet (di solito), i gateway predefiniti devono MAI essere utilizzati MAI per indicare un percorso a INTERNET. Se sono definiti più gateway predefiniti, il router del sistema operativo non può decidere quale utilizzare e se un gateway predefinito punta verso una strada senza uscita (ad es. La LAN multi-segmento), i pacchetti inoltrati lì per Internet sono non ce la farò.

— Adrien
fonte