none
Странности NLB и Site-to-Site VPN RRS feed

  • Вопрос

  • Есть два ISA-сервера, объединенные в массив. На всех интерфейсах кроме IntraArray включен NLB.
    Также настроены Site-to-Site туннели для офисов, некоторые офисы подключаются по PPTP, некоторые по IPsec.

    При этом наблюдается следующее странное поведение исы - при попытке подключиться скажем по RDP на внешний адрес любого из офисов, попытка может удаться, а может и нет, это зависит от того какой из членов массива взялся обслуживать подключение. Удается подключиться только к тем филиалам, VPN-ами которых в данный момент владеет член массива, обслуживающий мое соединение. Пинги при всем этом ходят нормально. И подключения внутри туннелей тоже обрабатываются нормально.

     

    Мониторинг пакетов дал следующие результаты:

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

     

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

    Инфа по версиям продуктов:
    Windows 2003 Enterprise SP1
    ISA 2004 Enterprise SP3 (тестировал и с SP1, ситуация такая-же)

    14 июня 2007 г. 13:20

Все ответы

  • Между сетями какое правило стоит? NAT или Routing? Фильтры есть?
    15 июня 2007 г. 7:04
    Модератор
  • Между Internal и VPN-нами стоит Routing, наружу естественно NAT.

    Пробовал вообще без фильтров Разрешено все ко всем.

     

    Да и до применения фильтров дело не доходит, так как пакет даже не регистрируется на втором сервере.

    15 июня 2007 г. 8:11
  •  Aluzar написано:

     

    Мониторинг пакетов дал следующие результаты:

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

     

     

     

    А куда он девается? Ответный пакет пришел, и вы его увидели в мониторинге как входящий, а как исходящий в локальную сеть нет?
    15 июня 2007 г. 8:34
    Модератор
  • В том то и вопрос - куда он девается?

    Ответный пакет приходит, и я его вижу только на внешнем интерфейсе, скажем Сервера SRV1, который владеет туннелем. А на внешнем интерфейсе второго сервера SRV2, пакет вообще не регистрируется.

    А так как запрос от клиентской машины изначально пришел на SRV2, то SRV1, получив ответ не пересылает его клиенту. Хотя в мониторе самой исы пакет проходит по правилу все_ко_всем, и резрешается.

    15 июня 2007 г. 8:44
  • Вы написали, что проблема возникает "при попытке подключиться скажем по RDP на внешний адрес любого из офисов," А если подключаться на внутренние адреса офисов (к.-л. удаленный сервер офиса) проблема остается или она только при таком подключении?
    15 июня 2007 г. 8:53
    Модератор
  • Если использовать внетренние адреса серверов, то никаких проблемм нет так как:

    если запрос клиента пришел на сервер не владеющий туннелем, то все пакеты маршрутизурются к владельцу туннеля через интерфейс IntraArray.

     

    Могу выложить логи неудачных соединений, если это внесет ясность.

    15 июня 2007 г. 9:01
  • Логи это хорошо.

    Но нужна схема соединений с адресами интерфейсов и сетей, а также таблицы маршрутизации обоих ISA.

     

    У вас адреса для удаленных соединений как заданы? Для каждого ISA свой диапазон должен быть, а какие у вас прописаны?

     

    Внешние адреса филиалов пингуете нормально?

    15 июня 2007 г. 9:18
    Модератор
  • Пингуется все нормально, проблемма только с tcp сессиями, возможно и с udp, не проверял.

    Пулы адресов для удаленных соединений следующие

    SRV1: 192.168.150.1-192.168.150.100

    SRV2: 192.168.150.101-92.168.150.200

    Схему соединений, логи неудачных сессий и таблицы маршрутизации залил сюда http://stream.ifolder.ru/2360569

    В них первые три октета реальных IP адресов Главного офиса заменены на 172.16.1. , первые три октета реальных IP адресов Филиала заменены на 172.16.3.

     

    Логи сессий писались на SRV1, SRV2 и клиенте. Сесия содержала:

    - Попытка пинга с клиента на внешний адрес сервера Филиала

    - Попытка подключиться telnet-ом на внешний адрес Филиала порт 3389

    15 июня 2007 г. 10:52
  • Я пока даже не буду смотреть ваши логи, потому что...

     

     

    Обратите внимание на ваши диапазоны. Они не совпадают с границами сетей. Если загляните в таблицы маршрутизации, то увидите, что у вас там для 192.168.150.* целая куча записей. Так?

     

    Выровните диапазоны, например так:

      

    SRV1: 192.168.150.0-192.168.150.127

    SRV2: 192.168.150.128-92.168.150.255

     

    Думаю после этого все заработает как надо.

     

     

    Не знаю почему ISA позволяет вводить "неправильные" диапазоны, но с ними не работает корректно это факт.

    15 июня 2007 г. 11:57
    Модератор
  • Не работало и с вариантом

    SRV1: 192.168.150.0-192.168.150.255

    SRV2: 192.168.151.0-192.168.151.255

    Но если Вы настаиваете, выровняю.

    15 июня 2007 г. 12:10
  • Выровнял, не помогло.

    А по поводу такой настройки:

    SRV1: 192.168.150.1-192.168.150.100

    SRV2: 192.168.150.101-92.168.150.200

    Прочитал кажется в каком-то гайде на microcoft.com, ссылка к сожалению не сохранилась.

    Первоначальная конфигурация как раз и была:

    SRV1: 192.168.150.0-192.168.150.255

    SRV2: 192.168.151.0-92.168.151.255

    Изменил во время эксперементов.

    15 июня 2007 г. 12:22
  • Вот и оставьте первоначальную конфгурацию

     

    SRV1: 192.168.150.0-192.168.150.255

    SRV2: 192.168.151.0-92.168.151.255

     

    Она самая правильная при NLB.

     

     

    Вы используете ISA Server integrated NLB?

    15 июня 2007 г. 13:15
    Модератор
  • Да, конечно. Ведь если использовать не в интегрированом режиме, то о Site-to-Site VPN-ах вообще можно забыть.
    15 июня 2007 г. 13:30
  • Попробовал еще и ISA 2006 и SP2 для Windows 2003, эффект, тот же.

    Собрал конфигурацию поновой, думал в старой во время эксперементов мог что-то не так сделать. Сейчас в конфигурации только правила необходимые для работы NLB и VPN и в правилах фильтрации разрешено все ко всем.

    Ситуация не меняется

    15 июня 2007 г. 13:37
  • После получасового изучения ваших логов я пришел к такому заключению.

     

    1. У вас все правильно настроено и правильно работает.
    2. "Странное" поведение,что называется, By design

    Вот цитата из документации:

     

     

    Connection Owner

    When a site-to-site connection is established with an array of ISA Server computers, only one array member is actually the connection owner. The connection owner is the VPN tunnel endpoint.

    When NLB is enabled, ISA Server automatically assigns the connection owner. No additional configuration is required. ISA Server uses an algorithm to optimize the connection owner assignment, creating as balanced a network as possible. After a tunnel has been established, the server assigned as the connection owner does not change, even if other servers are added or removed. If the assigned connection owner becomes unavailable, ISA Server automatically passes the connection to another array member. In this way, ISA Server supports failover for VPN site-to-site connections.

    When NLB is not enabled, you must assign a connection owner for the remote site network. If the connection owner becomes unavailable, there will be no connectivity to the remote site.

     

     

    Это означает, что реальный адрес удаленного конца туннеля выпадает из обработки NLB! Иначе говоря он обрабатывается всегда одним и тем же членом массива.

     

    Собственно это вы и установили.

     

     

     

    Workaround:

     

    Для доступа к удаленному серверу используйте его внутренний, а не реальный интернетовский, адрес.

     

     

     

    Что собственно более правильно: в Интернет все должно быть закрыто, а в локальную сеть можно открыть RDP.

     

     

     

     

    15 июня 2007 г. 14:08
    Модератор
  • В приведенной Вами цитате не сказано что адрес удаленного конца туннеля обрабатывается только одним сервером. И ICMP ведь работает нормально и обрабатывается обоими серверами. Хотя я скорее всего соглашусь что такое поведение обусловлено дизайном ISA.

    А использовать для соединения с филиалами только внутренний адрес хотел бы, но это не так просто. Так как туннели особенно PPTP имеют свойство падать при кратковременном обрыве связи, и не всегда могут подняться самостоятельно. Приходится их поднимать ручками, а как это сделать если не получается достучаться на внешний айпишник сервера?

    15 июня 2007 г. 14:16
  •  Aluzar написано:

    В приведенной Вами цитате не сказано что адрес удаленного конца туннеля обрабатывается только одним сервером. И ICMP ведь работает нормально и обрабатывается обоими серверами. Хотя я скорее всего соглашусь что такое поведение обусловлено дизайном ISA.

     

    Как раз про это и написано. Собственник соединения это призязка к удаленному ip, локальные они и так разные на членах массива.

     

    ICMP обрабатывается иначе, чем TCP. Даже если посмотрите собственные логи, то увидите, что пакеты ping одновременно идут через оба сервера.

     

     

     Aluzar написано:

    А использовать для соединения с филиалами только внутренний адрес хотел бы, но это не так просто. Так как туннели особенно PPTP имеют свойство падать при кратковременном обрыве связи, и не всегда могут подняться самостоятельно. Приходится их поднимать ручками, а как это сделать если не получается достучаться на внешний айпишник сервера?

     

    Соединение Site-to-Site должно подниматься автоматически как on-demand интерфейс. Если у вас не так, то надо  изучать ситуацию  и искать причину.

     

    Что касается RDP-соединения на реальный адрес удаленного сервера через NLB, то есть два варианта.

    1. Подключаться по RDP с сервера ISA.
    2. Поставить FWC, указав в нем не виртуальный адрес, а реальный адрес одного из серверов. Возможно потребуется призязка к реальному внешнему (не виртуальному) адресу (Параметр BindProxyIP).

     

     

     

     

     

     

    15 июня 2007 г. 15:24
    Модератор
  • Мне казлось, что владелец туннеля - это сервер, на котором в RRAS demand-dial интерфейс соответствующего соединения находится в состоянии Enable, соответственно только он может принимать входящие запросы на установку VPN туннеля (Это в случае PPTP, в случае IPsec туннеля будет сервер накотором присутствуют необходимые IPsec фильтры). Совершенно не понятно зачем разделять владельцев для TCP и UDP, когда можно было обойтись GRE, ESP и AH.

    Но это так, мысли вслух.

    Спорить с Вами не стану, так как не имею информации о том как оно все устроено на самом деле.

     

    А с on-demand интерфейсами - это сработает. если инициатором установки туннеля выступает ISA, а если удаленный сервер, то это вряд ли поможет.

    Ну а как подключиться по RDP к удаленному серверу в обход ISA можно придумать довольно много вариантов, например разместить в DMZ сециальный сервер, с которого потом и подключаться. Но вряд ли меня устроит такой вариант, поскольку дело не только в RDP есть еще нескоьлко сервисов, ктоторые используют для подключения внешние IP адреса.

    15 июня 2007 г. 18:36
  •  Aluzar написано:

    Мне казалось, что владелец туннеля - это сервер, на котором в RRAS demand-dial интерфейс соответствующего соединения находится в состоянии Enable, соответственно только он может принимать входящие запросы на установку VPN туннеля (Это в случае PPTP, в случае IPsec туннеля будет сервер накотором присутствуют необходимые IPsec фильтры). Совершенно не понятно зачем разделять владельцев для TCP и UDP, когда можно было обойтись GRE, ESP и AH.

     

    Когда туннелей много, то они распределяются между серверами ISA, т.о. все внешние интерфесы находятся в разрешенном состоянии, но NLB "знает", какой сервер должен обработать входящий пакет.

    Что касается протоколов, то когда вы включаете NLB в ISA, то вы включаете NLB в целом для всех протоколов. У ISA нет настроек типа "Включить NLB только для L2TP". Есть единственное разделение: можно включать NLB для конкретных сетей ISA.

    Именно это и создает вашу проблему!!!

     

    Вообще Integrated NLB это упрощенная настройка NLB, поэтому имеет целый ряд ограничений, работает только в unicast mode.....

     

     

     Aluzar написано:

    А с on-demand интерфейсами - это сработает. если инициатором установки туннеля выступает ISA, а если удаленный сервер, то это вряд ли поможет.

     

    При Site-to-Site соединении обе стороны равноправны и любая может инициировать соединение, если оно не установлено.

     

     Aluzar написано:

    Ну а как подключиться по RDP к удаленному серверу в обход ISA можно придумать довольно много вариантов, например разместить в DMZ сециальный сервер, с которого потом и подключаться. Но вряд ли меня устроит такой вариант, поскольку дело не только в RDP есть еще нескоьлко сервисов, ктоторые используют для подключения внешние IP адреса.

     

     

    Можно еще прописать на внутреннем роутере или клиентах статические маршруты.... или поднять динамику (RIP, OSPF)....

    18 июня 2007 г. 4:06
    Модератор
  •  sie написано:

    Когда туннелей много, то они распределяются между серверами ISA, т.о. все внешние интерфесы находятся в разрешенном состоянии, но NLB "знает", какой сервер должен обработать входящий пакет.

    Что касается протоколов, то когда вы включаете NLB в ISA, то вы включаете NLB в целом для всех протоколов. У ISA нет настроек типа "Включить NLB только для L2TP". Есть единственное разделение: можно включать NLB для конкретных сетей ISA.

    Именно это и создает вашу проблему!!!

    С NLB уже понял, он работает слоем между вторым и третим сетевым уровнем, и сам блокирует входящие соединения на все сервера кроме владельца туннеля. Похоже он делит протоколы на ICMP и все остальное :-).

     

     sie написано:

    При Site-to-Site соединении обе стороны равноправны и любая может инициировать соединение, если оно не установлено.

    В теории оно конечно так, но сейчас все настроено таким образом, что только филиал может инициировать соединения. Ну это исправимо конечно.

     

     sie написано:

    Можно еще прописать на внутреннем роутере или клиентах статические маршруты.... или поднять динамику (RIP, OSPF)....

     

    Сомневаюсь что статическими маршрутами получится обойтись, так как вледельцы туннелей распределяются динамически. И роутера перед ISA тоже нет, так как он стал бы единой точкой отказа, равно как и отдельная точка теминирования туннелей.

     

     

    18 июня 2007 г. 5:21
  • К сожалению не могу смоделировать ситуацию...

    Как вы определяете собственника соединения? Признаки какие? В таблице маршрутизации реальный адрес удаленой точки появляется?

    18 июня 2007 г. 5:41
    Модератор
  • Для PPTP и L2TP туннелей ISA создает в RRAS интерфейсы на каждом сервере массива. но в состоянии Enabled они находятся, только на сервере-владельце. Для IPsec на сервере-владельце, присутствуют фильтры IPsec для только для тех туннелей, которыми он владеет. А так как ISA пытается сбалансировать нагрузку, вызванную туннелированием, то она старается равномерно распределить туннели между серверами массива. Это иногда вызывает "миграцию" некоторых туннелей с одного сервера на другой. Проще говоря, ISA либо дисейблит на одном сервере соответсвующий туннель в RRAS. а на другом его энейблит, либо удаляет IPsec фильтр на одном. и добавляет на другом.
    18 июня 2007 г. 6:37
  • Кстати еще можно посмотреть, как intra-array настроен. Не думаю, что вы это упустили, но все же это тоже влияет. Должна быть intra-array network, она должна иметь network правило для выхода наружу и правило доступа разрешающее всем выход из этой сети наружу.

     

    18 июня 2007 г. 8:45
    Модератор
  •  sie написано:

    Кстати еще можно посмотреть, как intra-array настроен. Не думаю, что вы это упустили, но все же это тоже влияет. Должна быть intra-array network, она должна иметь network правило для выхода наружу и правило доступа разрешающее всем выход из этой сети наружу.

     

    Тоесть в Network Rules должно быть правило говорящее что доступ из IntraArray к External осуществлять через NAT, я так понимаю?

    18 июня 2007 г. 8:51
  • Да, именно так.

     

    Процедуры расписаны здесь http://www.microsoft.com/technet/isa/2004/plan/site_to_site_vpn_ee.mspx

     

    18 июня 2007 г. 8:55
    Модератор
  • Ну это я уже видел . Только там не ко всему External нужно правило писать, а ко всем удаленным серверам. И касается оно больше маршрутизации внутри туннеля. Есть у еня соответствующие правила конечно.

     

    Пора наверное сворачивать тему. И поискать приемлемые решения у других вендоров.

    18 июня 2007 г. 9:28
  • Я так и предполагал, что у вас все на месте.

     

    Если будет возможность, то я смоделирую ситуацию. Может кто еще имеет такую возможность? Если ограничение подтвердиться, то надо будет отписывать баг авторам.

     

    Удачи!

    18 июня 2007 г. 10:00
    Модератор