Windows 2008 Serverでのデッドゲートウェイの検出
最近、stackoverflow.comにHAProxyを実装しました。 TProxyを使用して、接続しているクライアントの送信元アドレスを維持することにしました。これにより、ログやその他のIISクライアントIPアドレスに依存するモジュールを変更する必要がなくなります。したがって、パケットは外部インターネットIPアドレスから送信されたかのように偽装されて到着しますが、実際にはローカルネットワーク上のローカル192.168.xx HAProxy IPから送信されます。
両方のWebサーバーには2つのNICがあります。1つは静的IP、DNS、デフォルトゲートウェイを備えたパブリックインターネット上のルーティング可能なクラスBアドレスで、もう1つはHAProxyのプライベートIPを指すデフォルトゲートウェイで構成されたルーティング不可能なプライベートクラスCアドレスです。 HAProxyには、パブリックとプライベートの2つのインターフェイスがあり、インターフェイス間でパケットを透過的にルーティングし、トラフィックを適切なWebサーバーに転送するジョブを実行します。
イーサネットアダプタインターネット： 説明。 。 。 。 。 。 。 。 。 。 。 ：ネットワークカード＃1 DHCPが有効。 。 。 。 。 。 。 。 。 。 。 ：いいえ 自動構成が有効です。 。 。 。 ：はい IPv4アドレス。 。 。 。 。 。 。 。 。 。 。 ：69.59.196.217（推奨） サブネットマスク。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.240 デフォルトゲートウェイ。 。 。 。 。 。 。 。 。 ：69.59.196.209 DNSサーバー。 。 。 。 。 。 。 。 。 。 。 ：208.67.222.222 208.67.220.220 NetBIOS over Tcpip。 。 。 。 。 。 。 。 ：有効 イーサネットアダプタプライベートローカル： 説明。 。 。 。 。 。 。 。 。 。 。 ：ネットワークカード＃2 DHCP有効。 。 。 。 。 。 。 。 。 。 。 ：いいえ 自動構成が有効です。 。 。 。 ：はい IPv4アドレス。 。 。 。 。 。 。 。 。 。 。 ：192.168.0.2（推奨） サブネットマスク。 。 。 。 。 。 。 。 。 。 。 ：255.255.255.0 デフォルトゲートウェイ。 。 。 。 。 。 。 。 。 ：192.168.0.50 NetBIOS overTcpip。 。 。 。 。 。 。 。 ：有効
各Webサーバーで自動メトリックを無効にし、ルーティング可能なパブリッククラスBにメトリック10を割り当て、プライベートインターフェイスにメトリック20を割り当てました。
また、これらのレジストリキーの両方を設定しました。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableDeadGWDetect"=dword:00000000
1日に約2回、Webサーバーの1つがDNSに接続できない、またはパブリックインターネット上の他のサーバーに接続できないという問題が発生します。
デッドゲートウェイの検出は、パブリックゲートウェイの停止を誤って検出し、すべてのトラフィックを、現時点ではDNSアクセスがないが、これを確認する方法がないプライベートゲートウェイに切り替えていると思われます。
デッドゲートウェイ検出が実行されているかどうか、またはWindows 2008サーバーのオプションでさえあるかどうかを知る方法はありますか？
もしそうなら、Windows2008サーバーでデッドゲートウェイ検出を無効にする方法はありますか？
そうでない場合、DNSを解決したり、短時間接続したりすることができなくなる他の理由がありますか？
Dead Gateway Detectionの動作を制御できなかった理由について、最終的な結果に到達できませんでした。
この問題のトラブルシューティングに多くの時間を費やすのではなく、HAProxyインスタンスがトラフィックをゲートウェイアウトバウンドにルーティングし、両方のWebサーバーのデフォルトゲートウェイをhaproxyのIPに設定し、内部ゲートウェイアドレスを削除することを選択しました。
[ 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
デッドデフォルトゲートウェイ検出が使用されなくなったため、問題を解消するデフォルトゲートウェイは1つだけになりました。
これらのDead Gateway Detection DWORDは、Windows Server 2008では役に立ちません。存在する唯一の理由は、互換性の理由です。 TCP/IPドライバーとWindowsルーターコンポーネントは、これらの値を検索しなくなりました。
この機能は、WindowsVistaでデビューした自動チューニングに組み込まれたと思われます。管理者特権のコマンドプロンプトで次のコマンドを実行してみてください（そして再起動します）。
netsh int tcp set global autotuninglevel = disabled
更新（2009年9月13日午後7時58分EST）に追加
それが機能しない場合は、より多くの診断出力が必要になります。 NetConnectionまたはLANシナリオのいずれかで（循環）トレースを開始し、問題が発生するまで実行を継続します。
netshトレース開始シナリオ= NetConnectionmaxSize = 512
（例：最大トレースログサイズが512MBのNetConnectionトレースシナリオを開始します）
結果のトレースを Network Monitor 3. で開くことができます。必ず、 最新のパーサー をインストールしてください。
なぜデフォルトゲートウェイをHAproxyに変更する必要があるのか疑問に思います。一般に、何か問題が発生した場合にゲートウェイIPが別のルーター/マシンにフェイルオーバーできる高可用性N + 1セットアップを指定しない限り、デフォルトゲートウェイを変更しないでください。 HAproxyマシンに何かが発生し、帯域外アクセスがなかった場合、Webサーバーはインターネットから切断されます。
これを行う理由は、セットアップでTproxyを使用して、プロキシサーバーのIPではなくクライアントのIPアドレスをログに表示するためだと思いますが、代わりにこれを行うことをお勧めします。
- HAproxy設定に「optionforwardfor ...」を追加します
- x-forwarded-for ISAPIフィルター をインストールします
- セットアップからtproxyを削除します
- デフォルトゲートウェイを、インターネットに直接接続して以前使用していたものと同じゲートウェイに戻します。
これをテストするためのWindowsマシンはありませんが、接続が失われることなく、目的の効果が得られるはずです。