Виявлення мертвих шлюзів на Windows 2008 Server

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

На обох наших веб-серверах є два NIC - одна маршрутизована адреса 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. . . . . . . . : Увімкнено

Приватний локальний адаптер:

   Опис . . . . . . . . . . : мережева карта №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 на даний момент, але не має можливості перевірити це.

1. Чи є спосіб дізнатися, чи працює виявлення мертвого шлюзу або навіть є опція на сервері Windows 2008?

2. Якщо так, чи є спосіб відключити виявлення мертвого шлюзу на сервері Windows 2008?

3. Якщо не могли бути інші причини, через які ми втрачаємо можливість вирішити DNS або підключитися на короткий час?

Ці DWORD-файли виявлення мертвих шлюзів марні на Windows Server 2008. Єдина причина їх існування - це причини сумісності. Драйвер TCP / IP та компоненти маршрутизатора Windows більше не шукають цих значень.

Я підозрюю, що ця функція була внесена до автоматичної настройки, яка дебютувала в Windows Vista. Спробуйте виконати наступне у підвищеному командному рядку (та перезавантажте):

netsh int tcp set global autotuninglevel = вимкнено

Оновлення ( додано 13 вересня 2009 р. О 7:00 58:00 EST )

Якщо це не працює, нам знадобиться більше діагностичного виводу. Почніть (круговий) слід з сценаріїв NetConnection або LAN і нехай він продовжує працювати, поки проблема не виникне.

netsh сценарій початку трасування = NetConnection maxSize = 512

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

Ви можете відкрити отриманий слід у Network Monitor 3.3 , просто переконайтеся, що встановили останні парсери .

Нам не вдалося досягти переконливого результату щодо того, чому ми не могли контролювати поведінку виявлення мертвих шлюзів.

Замість того, щоб витратити багато часу на усунення цієї проблеми, ми вирішили зробити наш трафік маршрутного примірника 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

Зараз існує лише один шлюз за замовчуванням, який усуває нашу проблему, оскільки виявлення мертвих шлюзів за замовчуванням більше не використовується.

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

Оскільки я вважаю, що причиною цього ви можете займатися є те, що ви використовуєте Tproxy у налаштуваннях, щоб IP-адреса клієнтів відображалася у ваших журналах, а не IP-адреса проксі-сервера, я можу запропонувати вам зробити це замість цього

1. Додайте "параметр forforfor ..." у свій конфігурацію HAproxy
2. Встановіть xAPredred-for ISAPI filter
3. Видаліть tproxy зі свого налаштування
4. Змініть шлюз за замовчуванням назад на той самий шлюз, який ви використовували раніше, при прямому підключенні до Інтернету

У мене немає машини Windows, щоб перевірити це, але я вважаю, що це повинно призвести до бажаного ефекту без небажаної втрати підключення.

Якщо залучається доступ до Інтернету (як правило), то для шлюзу за замовчуванням слід використовувати лише EVER для позначення шляху до INTERNET. Якщо у вас визначено кілька шлюзів за замовчуванням, маршрутизатор ОС не може вирішити, який з них використовувати, і якщо один шлюз за замовчуванням вказує вниз (наприклад, ваша багатосегментна локальна мережа), то пакети, переслані туди для Інтернету, не збирається встигнути.