Обнаружение мертвого шлюза на Windows 2008 Server

9

Недавно мы внедрили HAProxy для stackoverflow.com. Мы решили использовать TProxy для поддержки исходного адреса для клиентов, подключающихся, поэтому наши журналы и другие модули IIS, которые зависят от IP-адреса клиента, не требуют модификации. Таким образом, пакеты приходят с подделкой, как если бы они пришли с внешнего IP-адреса в Интернете, тогда как в действительности они пришли с локального 192.168.xx HAProxy IP в нашей локальной сети.

Оба наших веб-сервера имеют два сетевых адаптера: один маршрутизируемый адрес класса B в общедоступном Интернете со статическим IP-адресом, DNS-сервером и шлюзом по умолчанию, а также один частный не маршрутизируемый адрес класса C, настроенный со стандартным шлюзом, указывающим на частный IP-адрес для HAProxy. HAProxy имеет два интерфейса - один общедоступный и один частный и выполняет работу по прозрачной маршрутизации пакетов между интерфейсами и перенаправлению трафика на соответствующий веб-сервер.

Интернет-адаптер Ethernet:

   Описание . , , , , , , , , , , : сетевая карта № 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 через Tcpip. , , , , , , , : Включено

Адаптер Ethernet Private Local:

   Описание . , , , , , , , , , , : сетевая карта № 2
   DHCP включен. , , , , , , , , , , : Нет
   Автоконфигурация включена. , , , : Да
   IPv4-адрес. , , , , , , , , , , : 192.168.0.2 (предпочтительнее)
   Маска подсети . , , , , , , , , , , : 255.255.255.0
   Шлюз по умолчанию . , , , , , , , , : 192.168.0.50
   NetBIOS через Tcpip. , , , , , , , : Включено

Мы отключили автоматические метрики на каждом из веб-серверов и присвоили маршрутизируемому общедоступному классу 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 или подключаться на короткое время?

— Джефф Далгас
источник

1

Несмотря на то, что эта настройка иногда не одобряется (см. Blogs.technet.com/timmcmic/archive/2009/04/26/… ), она отлично работает для нас - весь трафик, приходящий с HAProxy на наши сайты IIS, выглядит так, как будто он все еще исходит от оригинальный IP-адрес. Это экономит огромное количество времени, поскольку нам нужно (узнать, как) настроить IIS и его многочисленные подключаемые модули для использования заголовка HTTP_X_FORWARDED_FOR.

— Джаррод Диксон

1

Почему у вас настроен шлюз на интерфейсе 192.168.0.2? Вы можете настроить пустой шлюз по умолчанию (и фактически это то, что Windows предлагает вам сделать, когда у вас есть два интерфейса).

— Портман

@Portman - поскольку наши веб-блоки видят трафик с неповрежденными исходными IP-адресами клиентов, ответы не будут отправляться в нашу сеть - поэтому у нас должен быть шлюз по умолчанию для нашего блока HAProxy.

— Джаррод Диксон

@Jarrod - эта конфигурация кажется подозрительной. А что если вы хотите запустить несбалансированный веб-сайт на этом веб-сервере? Ответ будет направлен через HAProxy? Как бы вы справились с чем-то вроде удаленного рабочего стола? Я понимаю, что это не решает вопрос, но это похоже на случай, когда вы делаете это неправильно, о чем (вежливо) говорит daivdsmalley.

— Портман

4

@ Джефф / Джефф / Джаррод - я не хочу констатировать очевидное, но вы, ребята, разработчики программного обеспечения, почему бы не нанять кого-то, кто является специалистом для ремонта дня? Это очень приятно, когда ваши руки пачкаются, но здесь есть явный пробел в знаниях, он периодически влияет на бизнес, и вы явно потратили немало драгоценного времени, не используя свои основные навыки, а именно развитие. Поверь мне, найди кого-нибудь, чтобы починить, а потом выбери себе мозги после того, как все заработало. Черт, даже как веб-хостеры, мы должны привлечь людей, чтобы преодолеть эти пробелы, когда это критично для миссии / обслуживания.

— Кев

5

Эти DWORD обнаружения мертвых шлюзов бесполезны в Windows Server 2008. Единственная причина, по которой они существуют, - это соображения совместимости. Драйвер TCP / IP и компоненты маршрутизатора Windows больше не ищут эти значения.

Я подозреваю, что эта функция была включена в Auto-Tuning, которая дебютировала в Windows Vista. Попробуйте выполнить следующее в командной строке с повышенными правами (и перезагрузите компьютер):

netsh int tcp set global autotuninglevel = отключено

Обновление ( добавлено 13 сентября 2009 г., 7: 58 вечера EST )

Если это не сработает, нам понадобится больше диагностических данных. Запустите (круговую) трассировку с использованием сценариев NetConnection или LAN и дайте ему продолжаться, пока не возникнет проблема.

сценарий запуска трассировки netsh = NetConnection maxSize = 512

_{(Пример: запускает сценарий трассировки NetConnection с максимальным размером журнала трассировки 512 МБ)}

Вы можете открыть полученную трассировку в Network Monitor 3.3 , просто убедитесь, что вы установили последние парсеры .

— Рафаэль Ривера
источник

хорошая идея, но, похоже, тоже не сработала ... только что пережил 5-минутный перерыв в исходящем трафике - который загадочным образом исправился.

— Джефф Этвуд

@Джефф: Хм, нам нужно больше данных, капитан! Смотрите редактирование выше.

— Рафаэль Ривера

5

Мы не смогли прийти к окончательному результату относительно того, почему мы не могли контролировать поведение Обнаружения Мертвых Ворот.

Вместо того чтобы тратить кучу времени на устранение этой проблемы, мы решили направить трафик нашего экземпляра 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

Теперь существует только один шлюз по умолчанию, который устраняет нашу проблему, потому что обнаружение мертвого шлюза по умолчанию больше не используется.

— Джефф Далгас
источник

4

Я хотел бы спросить, почему вам вообще нужно изменить шлюз по умолчанию, чтобы он был HAproxy вообще. Как правило, вам вообще не следует менять шлюз по умолчанию, если только вы не указываете на высокодоступную настройку N + 1, где IP-адрес шлюза может переключаться на другой маршрутизатор / машину в случае чего-то плохого. Если что-то случится с вашей машиной HAproxy, и у вас не будет никакого внешнего доступа, тогда веб-серверы просто отключатся от Интернета.

Как я полагаю, причина, по которой вы, возможно, делаете это, заключается в том, что вы используете Tproxy в своих настройках, чтобы IP-адреса клиентов отображались в ваших журналах, а не IP-адрес прокси-сервера. Могу ли я предложить вам сделать это вместо этого?

Добавьте «option forwardfor ...» в конфигурацию HAproxy
Установите фильтр ISAPI для x-forwarded-for
Удалите tproxy из вашей настройки
Измените шлюз по умолчанию обратно на тот же шлюз, который вы использовали ранее с прямым подключением к Интернету.

У меня нет машины с Windows, чтобы проверить это, но я считаю, что это должно привести к желаемому эффекту без нежелательной потери связи.

— davidsmalley
источник

Я только заметил ваш комментарий на оригинальный вопрос, касающийся этой настройки. Тем не менее, я сомневаюсь, что «у нас это работает отлично», если ваши серверы теряют интернет-соединение :)

— davidsmalley

3

В качестве альтернативы вы могли бы взглянуть на гораздо более надежное решение, такое как ldirectord + heartbeat, которое просто перенаправляет трафик на уровне ядра, поэтому прокси-сервер вообще не задействован. Я широко использую эту настройку, и она прекрасно работает. linuxvirtualserver.org/docs/ha/heartbeat_ldirectord.html

— davidsmalley

Мы рассмотрели использование этого x-forwarded-forзаголовка и фильтров IIS для изменения журналов, но мы не знаем, как (или если) наши другие дополнительные модули IIS также используют заголовок в своей работе.

— Джаррод Диксон

Спасибо за эту ссылку linuxvirtualserver.org/HighAvailability.html - там удивительная информация! Я не в курсе этих предметов (именно поэтому я не единственный, кто все это готовит!), Но я стараюсь учиться как можно быстрее. Возможно, мы можем использовать heartbeat + ldirectord, аналогично тому, как linuxvirtualserver.org/docs/ha/ultramonkey.html делает это с нашим любимым HAProxy.

— Джаррод Диксон

-1

Когда используется доступ в Интернет (обычно), то шлюзы по умолчанию должны использоваться НИКОГДА для обозначения пути к ИНТЕРНЕТУ. Если у вас определено несколько шлюзов по умолчанию, маршрутизатор ОС не может решить, какой из них использовать, и если один шлюз по умолчанию указывает на тупик (например, вашу многосегментную локальную сеть), то пакеты, пересылаемые туда для Интернета, не собираюсь это сделать.

— Adrien
источник