Windows 2008 Server'da ölü ağ geçidi algılama

Yakın zamanda stackoverflow.com için HAProxy uyguladık. Günlüklerimizin ve istemci IP adresine bağlı diğer IIS modüllerinin değiştirilmesini gerektirmeyecek şekilde bağlanan istemciler için kaynak adresini korumak amacıyla TProxy kullanmaya karar verdik. Böylece paketler, harici bir internet IP adresinden gelmiş gibi sahte olarak gelir, gerçekte yerel ağımızdaki yerel bir 192.168.xx HAProxy IP'den geldiklerinde.

Her iki web sunucumuz da iki NIC'ye sahiptir - statik internet, DNS ve varsayılan ağ geçidine sahip genel internette bir yönlendirilebilir B sınıfı adresi ve HAProxy için özel IP'ye işaret eden varsayılan bir ağ geçidi ile yapılandırılmış bir özel yönlendirilemeyen sınıf C adresi. HAProxy'nin iki arabirimi vardır - biri genel, diğeri özel ve paketleri arabirimler arasında şeffaf olarak yönlendirme ve trafiği uygun web sunucusuna yönlendirme işini gerçekleştirir.

Ethernet adaptörü İnternet:

   Açıklama . . . . . . . . . . . : ağ kartı # 1
   DHCP Etkin. . . . . . . . . . . : Hayır
   Otomatik Yapılandırma Etkin. . . . : Evet
   IPv4 Adresi. . . . . . . . . . . : 69.59.196.217 (Tercih Edilen)
   Alt Ağ Maskesi. . . . . . . . . . . : 255.255.255.240
   Varsayılan giriş . . . . . . . . . : 69.59.196.209
   DNS Sunucuları. . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   Tcpip üzerinden NetBIOS. . . . . . . . : Etkin

Ethernet adaptörü Özel Yerel:

   Açıklama . . . . . . . . . . . : ağ kartı # 2
   DHCP Etkin. . . . . . . . . . . : Hayır
   Otomatik Yapılandırma Etkin. . . . : Evet
   IPv4 Adresi. . . . . . . . . . . : 192.168.0.2 (Tercih Edilen)
   Alt Ağ Maskesi. . . . . . . . . . . : 255.255.255.0
   Varsayılan giriş . . . . . . . . . : 192.168.0.50
   Tcpip üzerinden NetBIOS. . . . . . . . : Etkin

Web sunucularının her birinde otomatik metrikleri devre dışı bıraktık ve yönlendirilebilir genel B sınıfı 10'luk bir metrik ve özel arayüzümüze 20'lik bir metrik verdik.

Ayrıca bu kayıt defteri anahtarlarının her ikisini de ayarladık:

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

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

Günde yaklaşık iki kez, web sunucularından birinin DNS ile iletişim kuramadığı veya herkese açık internetteki diğer sunucularla bağlantı kuramadığı sorunlar görüyoruz.

Ölü ağ geçidi algılamasının halka açık ağ geçidindeki bir kesintiyi yanlış algıladığından ve tüm trafiği bu noktada DNS erişimi olmayan ancak bunu doğrulamanın bir yolu olmayan özel ağ geçidine geçirdiğinden şüpheleniyoruz.

1. Ölü ağ geçidi algılamanın çalışıp çalışmadığını veya hatta Windows 2008 sunucusunda bir seçenek olup olmadığını bilmenin bir yolu var mı?

2. Öyleyse, Windows 2008 sunucusunda ölü ağ geçidi algılamasını devre dışı bırakmanın bir yolu var mı?

3. Değilse, DNS'yi çözme veya kısa bir süre için bağlantı kurma yeteneğimizi kaybetmemizin başka nedenleri olabilir mi?

Bu Ölü Ağ Geçidi Algılama DWORD'leri Windows Server 2008'de işe yaramaz. Var olmasının tek nedeni uyumluluk nedenidir. TCP / IP sürücüsü ve Windows yönlendirici bileşenleri artık bu değerleri aramıyor.

Bu özelliğin Windows Vista'da çıkış yapan Auto-Tuning'e dönüştürüldüğünden şüpheleniyorum. Yükseltilmiş bir komut isteminde aşağıdakileri çalıştırmayı deneyin (ve yeniden başlatın):

netsh int tcp set global autotuninglevel = devre dışı

Güncelleme ( 13 Eylül 2009 @ 7: 58PM EST eklendi )

Bu işe yaramazsa, daha fazla tanı çıktısına ihtiyacımız olacak. NetConnection veya LAN senaryolarıyla (dairesel) bir izleme başlatın ve sorun oluşana kadar çalışmaya devam etmesine izin verin.

netsh izleme başlangıç ​​senaryosu = NetConnection maxSize = 512

_{(Örnek: NetConnection izleme senaryosunu maksimum izleme günlük boyutu 512 MB ile başlatır)}

Elde edilen izlemeyi Ağ İzleyicisi 3.3'te açabilirsiniz, en son ayrıştırıcıları yüklediğinizden emin olun .

Dead Gateway Detection'ın davranışını neden kontrol edemediğimiz konusunda kesin bir sonuca varamadık.

Bu sorunu gidermek için tonlarca zaman harcamak yerine, HAProxy bulut sunucusu yönlendirme trafiğimizi ağ geçidine giden yola yönlendirmeyi seçtik ve her iki web sunucusunun da varsayılan ağ geçidini haproxy IP'sine ayarladık ve dahili ağ geçidi adresini kaldırdık.

  [ 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

Artık ölü varsayılan ağ geçidi algılaması artık kullanılmadığından sorunumuzu ortadan kaldıran tek bir varsayılan ağ geçidi var.

Neden varsayılan ağ geçidini HAproxy olarak değiştirmeniz gerektiğini bile soruyorum. Genellikle, ağ geçidi IP'sinin kötü bir şey olması durumunda başka bir yönlendiriciye / makineye yük devretebileceği yüksek düzeyde kullanılabilir bir N + 1 kurulumuna işaret etmediğiniz sürece varsayılan ağ geçidinizi değiştirmemelisiniz. HAproxy makinenize bir şey olduysa ve bant dışı erişiminiz yoksa, web sunucuları internetten düşecektir.

Bunu yapmanıza neden olabileceğine inandığımdan, istemcilerin IP adreslerinin proxy sunucunuzun IP'sinde değil günlüklerinizde görünmesini sağlamak için kurulumunuzda Tproxy kullandığınızdan, bunun yerine bunu önerebilir miyim

1. HAproxy yapılandırmanıza "ileriye yönelik seçenek ..." ekle
2. Yükleme x iletilen-için ISAPI filtresi
3. Tproxy kurulumundan kaldırın
4. Varsayılan ağ geçidini, doğrudan internet bağlantısı ile daha önce kullandığınız ağ geçidine geri döndürün

Bunu test etmek için bir Windows makinem yok, ancak istenmeyen bağlantı kaybı olmadan istenen etkiye neden olması gerektiğine inanıyorum.

İnternet erişimi söz konusu olduğunda (genellikle) varsayılan ağ geçitleri İNTERNET'e giden bir yolu belirtmek için yalnızca EVER kullanılmalıdır. Tanımlanmış birden çok varsayılan ağ geçidiniz varsa, OS yönlendiricisi hangisini kullanacağınıza karar veremez ve bir varsayılan ağ geçidi bir çıkmaz noktayı (örneğin çok bölümlü LAN'ınız) gösterirse, o zaman internet için iletilen paketler başaramayacak.