Недавно мы реализовали HAProxy для stackoverflow.com. Мы решили использовать TProxy для поддержки исходного адреса для подключающихся клиентов, чтобы наши журналы и другие модули IIS, которые зависят от IP-адреса клиента, не нуждались в модификации. Таким образом, пакеты прибывают подделанными, как если бы они пришли с внешнего IP-адреса в Интернете, хотя на самом деле они пришли с локального IP-адреса 192.168.x.x HAProxy в нашей локальной сети.
Оба наших веб-сервера имеют два сетевых адаптера - один маршрутизируемый адрес класса B в общедоступном Интернете со статическим IP, DNS и шлюзом по умолчанию и один частный немаршрутизируемый адрес класса C, настроенный со шлюзом по умолчанию, указывающим на частный IP-адрес для HAProxy. HAProxy имеет два интерфейса - публичный и частный, и выполняет задачу прозрачной маршрутизации пакетов между интерфейсами и направления трафика на соответствующий веб-сервер.
Ethernet adapter Internet:
Description . . . . . . . . . . . : network card #1
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 69.59.196.217 (Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.240
Default Gateway . . . . . . . . . : 69.59.196.209
DNS Servers . . . . . . . . . . . : 208.67.222.222
208.67.220.220
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter Private Local:
Description . . . . . . . . . . . : network card #2
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.2 (Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.50
NetBIOS over Tcpip. . . . . . . . : Enabled
Мы отключили автоматические метрики на каждом из веб-серверов и назначили маршрутизируемому общедоступному классу 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
Примерно два раза в день мы сталкиваемся с проблемами, когда один из веб-серверов не может связаться с DNS или установить соединение с любыми другими серверами в общедоступном Интернете.
Мы подозреваем, что обнаружение неработающего шлюза ложно определяет сбой на общедоступном шлюзе и переключает весь трафик на частный шлюз, который на данный момент не имеет доступа к DNS, но не имеет возможности проверить это.
Есть ли способ узнать, работает ли обнаружение мертвого шлюза или даже есть ли опция на сервере Windows 2008?
Если да, то есть ли способ отключить обнаружение мертвого шлюза на сервере Windows 2008?
Если нет, могут ли быть другие причины, по которым мы теряем способность разрешать DNS или подключаться на короткое время?
Мы не смогли прийти к окончательному результату относительно того, почему мы не могли контролировать поведение функции обнаружения мертвых шлюзов.
Вместо того, чтобы тратить массу времени на устранение этой проблемы, мы решили направить трафик нашего экземпляра HAProxy на исходящий шлюз и установить для обоих веб-серверов шлюз по умолчанию на IP-адрес haproxy и удалить внутренний адрес шлюза.
[ 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
Теперь есть только один шлюз по умолчанию, который устраняет нашу проблему, потому что обнаружение мертвого шлюза по умолчанию больше не используется.
Эти DWORD обнаружения мертвого шлюза бесполезны в Windows Server 2008. Единственная причина, по которой они существуют, - это соображения совместимости. Драйвер TCP / IP и компоненты маршрутизатора Windows больше не ищут эти значения.
Я подозреваю, что эта функция была добавлена в автонастройку, которая дебютировала в Windows Vista. Попробуйте выполнить следующее в командной строке с повышенными привилегиями (и перезагрузитесь):
netsh int tcp set global autotuninglevel=disabled
Обновить (добавлена 13 сентября 2009 @ 7: 58PM EST)
Если это не сработает, нам потребуются дополнительные диагностические данные. Запустите (циклическую) трассировку либо со сценарием NetConnection, либо со сценарием LAN, и позвольте ему продолжать работу, пока не возникнет проблема.
netsh trace start scenario=NetConnection maxSize=512
(Пример: запускает сценарий трассировки NetConnection с максимальным размером журнала трассировки 512 МБ)
Вы можете открыть получившуюся трассировку в Сетевой монитор 3.3, просто убедитесь, что вы установили последние парсеры.
Я бы спросил, зачем вам вообще нужно менять шлюз по умолчанию на HAproxy. Как правило, вам не следует менять свой шлюз по умолчанию вообще, если вы не указываете его на высокодоступную настройку N + 1, где IP-адрес шлюза может переключиться на другой маршрутизатор / машину в случае чего-то плохого. Если что-то случится с вашим компьютером HAproxy и у вас не будет внеполосного доступа, тогда веб-серверы просто отключатся от Интернета.
Поскольку я считаю, что причина, по которой вы можете это делать, заключается в том, что вы используете Tproxy в своей настройке, чтобы IP-адрес клиентов отображался в ваших журналах, а не IP-адрес прокси-сервера, могу ли я предложить вам сделать это вместо
У меня нет компьютера с Windows, на котором можно это проверить, но я считаю, что это должно привести к желаемому эффекту без нежелательной потери связи.
Когда используется доступ в Интернет (обычно), то шлюзы по умолчанию должны использоваться ВСЕГДА только для обозначения пути в ИНТЕРНЕТ. Если у вас определено несколько шлюзов по умолчанию, маршрутизатор ОС не может решить, какой из них использовать, и если один шлюз по умолчанию указывает на тупик (например, вашу многосегментную локальную сеть), то пакеты, пересылаемые туда для Интернета, являются не собираюсь этого делать.