none
TMG NLB один из узлов нужно мигрировать на другой vcenter NIC изменятся RRS feed

  • Вопрос

  • Здравствуйте, какая-то неоднозначная ситуация, нужен совет.

    У меня в виртуальной среде (vmware) два tmg 2010 сервера - члены nlb кластера. Возникла необходимость один из двух серверов перенести под управление другого vCenter, соответственно пользую vCenter Standalone Converter. Переносится без проблем, проблемы начинаются дальше.

    Каждый из серверов имеет по три интерфейса (WAN, LAN, DMZ), соответственно, когда я мигрировал vm tmg02 у меня появляется машина с тремя новыми интерфейсами (mac адреса другие, все ip адреса сброшены). Как мне вернуть мигрировавший tmg02 в nlb кластер.

    Если абстрагироваться от виртуализации, у меня получается ситуация когда в tmg02 физически заменили все три сетевых адаптера. Как можно его оживить, может быть есть где-то описание что делать в таком случае?

    В общем нужен совет, спасибо.

    1 августа 2013 г. 15:02

Ответы

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

    Площадка1:

    Коммутатор HP5820 с портом А1, куда подключена вм TMG01

    Площадка2:

    Коммутатор HP5820 с портом А2, куда подключена вм TMG02

    1. Вариант1.  Мы отрубаем на П1 LAN интерфейс.
      1.        Допустим, на НР мы видим, что мак адрес NLB 10.62.7.253 приходит с А1.
      2.       Отключаем LAN интерфейс TMG01
      3.        Поскольку мы его выключили мак NLB кластера приходит с А2 теперь и НР при установлении tcp сессии отправляет запросы на 10.62.7.253 на А2.
      4.       Ну и соответственно все DMZ интерфейсы мы видим.
      5.       Все корректно, NLB не теряем
    2. Вариант2.  Мы отрубаем на П1 DMZ интерфейс, но при этом LAN не вырубаем.
      1.        Допустим, на НР мы видим, что мак адрес NLB 10.62.7.253 приходит с А1.
      2.       На НРах прописан статический маршрут, сеть 10.62.1.0 заруливается на 10.62.7.253
      3.        Пингуем TMG02 интерфейс DMZ 10.62.1.252
      4.       Пакет доходит до НР, НР знает что его нужно зарулить на 10.62.7.253 и знает, что 10.63.7.253 у нее на А1, т.е. сессия устанавливается с TMG01 и пинг 10.62.1.252 идет именно через него.
      5.       В данной ситуации мы отключаем TMG01 DMZ 10.62.1.251, и теряем 10.62.1.253, 10.62.1.252
      6.         Так происходит потому, что НР пакеты на 10.62.1.252 отправляет на 7.253 на А1, т.е. на TMG01, а на нем не доступен интерфейс DMZ. Ключевой момент в том, что НР отправляя пакеты в DMZ видит, что 7.253 доступен на А1 и отправляет туда – TMG01 с недоступным DMZ.
      7.        И так будет до тех пор, пока НР не узнает, что 7.253 у нее приходит с порта А2, а этого не произойдет пока не отключится интерфейс LAN на TMG01.
      8.       Теперь мы выключаем LAN интерфейс на TMG01
      9.          НР по прежнему считает, что мак адрес LAN NLB приходит с А1, до тех пор пока у нее не обновится таблица ARP (по умолчанию 20 минут). И замечательно отправляет запросы DMZ и LAN в порт А1, а там некому ответить – оба интерфейса на TMG01 выключены.
      10.         Делаем на НР время старения АРП записей – 1 минуту.
      11.        Через 1 минуту НР узнает, что мак LAN NLB прилетает с А2 и начинает слать запросы DMZ и LAN на А2, где у нас TMG02 с живыми интерфейсами LAN и DMZ
      12.          Соответственно оба NLB LAN и DMZ становятся доступными.
    3. Зачем отключать проверку спуфинга на ТМГ
      1.        Из-за статического маршрута на HP, допустим мы пингаем П2 TMG02 DMZ 10.62.1.252 (который имеет второй адрес НЛБ 10.62.1.253) в то время как НР знает, что 10.62.7.253 у нее на А1 П1.
      2.  Получается, что сессия с 10.62.1.252 устанавливается, через TMG01 у которого интерфейс DMZ имеет два адреса 10.62.1.251 и 10.62.1.253, т.е. сессия устанавливается с TMG01. 

    • Помечено в качестве ответа Aleksey Ozerov 8 августа 2013 г. 12:18
    8 августа 2013 г. 12:18

Все ответы

  • Здравствуйте,

    Поясните пожалуйста:

    После миграции вы создали на виртуальных свитчах порт группы с такими же настройками, подключили к ним интерфейсы, назначили такие же IP адреса и при таком раскладе на TMG не стартуют службы?  

    Или службы поднялись, но NLB кластер не собирается? 

    Или интерфейсы в RRAS не видны?




    • Изменено SemenovA 1 августа 2013 г. 16:32 орфо
    1 августа 2013 г. 16:23
  • Спасибо за ответ, происходит следующее:

    Я создал порты группы с такими же настройками, подключил к ним интерфейсы, прописал те же адреса, все службы TMG стартанули, NLB включился, но в RRAS интерфейсов не видно...

    2 августа 2013 г. 3:07
  • Скажите, пожалуйста, это обсуждение не смотрели?
    2 августа 2013 г. 5:35
  • Спасибо за ссылку, я ее сохранил.
    Решил сделать по другому, у нас в компании используется Veeam B&R, с его помощью я осуществил миграцию tmg02 на другой vcenter с сохранением NIC адаптеров и MAC адресов, вроде все поднялось, есть один настораживающий момент. Интерфейс, который смотрит в DMZ.

    1. Данный интерфейс на tmg01 я могу пинговать из LAN и из DMZ (разрешающие правила - есть)
    2. А вот с tmg02 беда, из Lan не пингуется, в логах TMG: "A packet was dropped because Forefront TMG determined that the source IP address is spoofed. " Из DMZ пингуется.

    Непонятно как-то, если я активирую tmg02 на первом vcenter (откуда осуществлял миграцию) DMZ интерфейс из LAN пингуется, если опять активирую на vcenter02 - интерфейс tmg02 DMZ из LAN не пингуется...
    2 августа 2013 г. 10:28
  • Сравните настройки порт группы для этого интерфейса, особенно настройку Notify switches.
    И скажите, в каком режиме у Вас работает NLB?
    • Изменено SemenovA 2 августа 2013 г. 10:39 орфография
    2 августа 2013 г. 10:32
  • Настройки порт группы - одинаковые, Notify switches - отключено, NLB - Multicast
    2 августа 2013 г. 10:53
  • Можно глянуть тут http://blogs.technet.com/b/isablog/archive/2010/08/18/understanding-a-scenario-where-tmg-drops-the-packet-as-spoofed-even-when-the-source-ip-doesn-t-belong-to-the-internal-network.aspx

    Сетевые карточки случаем не перепутались?

    • Изменено SemenovA 2 августа 2013 г. 11:16 орфо
    2 августа 2013 г. 11:06
  • Спасибо за совет, но я отключил проверку спуфинга адресов на TMG, не знаю насколько это было решение верным, но я сделал именно так:

    http://support.microsoft.com/kb/838114/en-us


    • Изменено Aleksey Ozerov 2 августа 2013 г. 12:30 ошибки
    2 августа 2013 г. 12:30
  • Рано, я видимо обрадовался, пришлось все равно все откатить на одну площадку, какие-то непонятки. Попробую описать что у меня получается:

    Есть две георгафически разнесенные площадки: П1 и П2, на каждой из них стоят HP5820, которые соединены в одно логическое устройство, на обоих площадках используется одна ИП адресация. 

    Интерфейс LAN (VLAN 63):
    TMG01 10.62.4.81
    TMG02 10.62.4.82
    LAN (nlb) – 10.62.7.253

    Интерфейс DMZ (VLAN 77):
    TMG01 10.62.1.251
    TMG02 10.62.1.252
    DMZ (nlb) – 10.62.1.253

    Смотрим вариант когда TMG1 и TMG2 находятся на vcenter, на П1:

    Мы выключаем на TMG01 интерфейс LAN 10.62.4.81
    Теряем: 10.62.4.81; 10.62.1.251 (непонятно почему, но DMZ интерфейс тоже теряется)
    Видим: 10.62.7.253; 10.62.4.82; 10.62.1.252; 10.62.1.253

    Мы выключаем на TMG02 интерфейс LAN 10.62.4.82
    Теряем: 10.62.4.82; 10.62.1.252
    Видим: 10.62.7.253; 10.62.4.81; 10.62.1.251; 10.62.1.253

    Смотрим вариант когда TMG1 на П1 и TMG2 на П2 находятся на разных vcenter:

    Мы выключаем на TMG01 интерфейс LAN 10.62.4.81
    Теряем: 10.62.4.81; 10.62.1.251; 10.62.1.252 (TMG02 DMZ); 10.62.1.253 (DMZ nlb) – вообщпе не понятно DMZ кластер недоступен!
    Видим: 10.62.4.82; 10.62.7.253 

    Мы выключаем на TMG02 интерфейс LAN 10.62.4.82
    Теряем: 10.62.4.82; 10.62.1.252
    Видим: 10.62.7.253; 10.62.4.81; 10.62.1.251; 10.62.1.253

    И я как-то запутался в этой ситуации, по второму варианту, когда TMG на разных площадках, у удалял все сетевые интерфейсы и добавлял новые с новыми MAC адресами, адреса NLB кластеров - остались как были...

    Нужны мысли, потому-что мои закончились, спасибо...

    5 августа 2013 г. 15:00
  • Скажите, пожалуйста, Вы используете распределенный коммутатор?

    Если да, то посмотрите, пожалуйста в свойствах порт групп (для DMZ и LAN) какая настройка стоит для Port Binding? Если стоит Static Binding - создайте идентичную портгруппу, но выставите Dynamic binding или  Ephemeral и перенесите туда интерфейсы DMZ/LAN для TMG2. После этого перенесите TMG2 при помощи Veeam на площадку 2 и попробуйте запуститься. 


    • Изменено SemenovA 5 августа 2013 г. 18:06 орфо
    5 августа 2013 г. 18:03
  • Спасибо за ответ.

    Если мы говорим про vcenter - то нет, распределенный коммутатор не используем, для каждого хоста настроен свой.

    6 августа 2013 г. 2:06
  • Как Вы сами понимаете - проблема с DMZ интерфейсом при переносе, поэтому у Вас DMZ nlb кластер падает при отключении TMG1. На площадке №2 есть связанность между VLAN66, VLAN77 и VLAN (не знаю как называется, для ip 10.62.7.253)? Можно провести эксперимент: настроить для 2 машинок nlb кластер по аналогии с кластером TMG и перетащить одну из машинок на второй VC. Если все пройдет нормально, нужно разбираться почему на TMG2 из LAN не пингуется DMZ интерфейс. Если нет - разбираться с настройками сетевого оборудования.     
    6 августа 2013 г. 6:22
  • В общем вопрос почему теряется DMZ при отключении LAN выяснен, поскольку прописан маршрут на DMZ подсеть через через шлюз TMG 10.62.7.253  - как раз тот который мы и отключаем, в общем этот вопрос снят. Теперь про эксперименты.

    Завел на разных площадках две тестовые машины Т1 и Т2, на каждой настроил NLB в VLAN63 (LAN) и VLAN77 (DMZ), действительно кластера ведут себя не правильно до тех пор, пока не разрешишь для MAC адресов в VLANах mulicast yна портах куда машинки приходят. Я говорю о физических портах коммутатора куда подключен гипервизор, что-то типа этого:

    mac-address multicast 03bf-0a3e-044d vlan 63

    mac-address multicast 03bf-0a3e-0133 vlan 77

    Но, но для TMG это проделано и я пока так и не понял в чем дело.

    Сейчас попробую сделать эксперимент еще более приближенным к реальности, заведу обе машины и NLB кластера на одной площадке и потом перенесу.... но как-то странно...

    6 августа 2013 г. 9:47
  • В проделал я эксперимент с заведением обоих машин на одной площадке и миграции второй тестовой машины на вторую площадку - оба NLB работают как и ожидалось....

    Вот теперь я полностью потерялся.... куда смотреть в узлы TMG не могу даже предположить

    6 августа 2013 г. 14:46
  • Я не сетевик, но если нужно разрешать в VLAN mac, тот не нужно ли их потом убирать, если не используются? Я имею ввиду -не нужно ли убрать mac адреса для TMG2 с настроек порта коммутатора на площадке 1? 

    Может стоит посмотреть в сторону маршрутов на TMG2 (в плане спуфинга)? Тут описано в каких случаях возникает ошибка spoofing detection:

    http://technet.microsoft.com/ru-ru/library/cc995155.aspx

    http://blogs.technet.com/b/isablog/archive/2010/08/18/understanding-a-scenario-where-tmg-drops-the-packet-as-spoofed-even-when-the-source-ip-doesn-t-belong-to-the-internal-network.aspx

    6 августа 2013 г. 15:02
  • Спасибо за поддержку :)

    Нет, МАК адреса убирать нельзя, т.к. это адреса NLB кластеров, а ТМГ1 остался на первой площадке на тех же портах, т.е. с записи адресов должны быть, как и показал мой эксперимент без них NLB на тестовых машинах работает некорректно.

    Вот про спуфинг - видимо здесь вся проблема и есть, не зря же ТМГ ругался, осталось только вычислить каким образом это происходит... в общем изыскательские работы продолжаются...

    Спасибо за ссылки, буду ковырять...

    7 августа 2013 г. 2:41
  • Что-то никак...

    Если абстрагироваться от того что я разносил узлы, просто забыть.

    Есть у меня TMG01 с DMZ интерфейсом 10.62.1.251

    Есть TMG02 с  DMZ интерфейсом 10.62.1.252

    Они собраны в NLB 10.62.1.253

    Пингую из локальной сети (не ДМЗ) пинг на 10.62.1.251 проходит, на 10.62.1.252 - не идет отваливается по таймауту, причем в логах TMG пишет о том, что:

    Log type: Firewall service 
    Status: A packet was dropped because Forefront TMG determined that the source IP address is spoofed.  
    Rule: None - see Result Code 
    Source: Internal (10.62.8.13:2048) 
    Destination: Local Host (10.62.1.252) 

    Я разобрал DMZ nlb, все равно интерфейс второго не пингуется

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


    • Изменено Aleksey Ozerov 7 августа 2013 г. 13:44 дополнил
    7 августа 2013 г. 13:41
  • В общем, к своей радости, сообщаю, что проблема побеждена, постараюсь разложить по полочкам в чем было дело, кому-то может быть тоже пригодится.

    Площадка1:

    Коммутатор HP5820 с портом А1, куда подключена вм TMG01

    Площадка2:

    Коммутатор HP5820 с портом А2, куда подключена вм TMG02

    1. Вариант1.  Мы отрубаем на П1 LAN интерфейс.
      1.        Допустим, на НР мы видим, что мак адрес NLB 10.62.7.253 приходит с А1.
      2.       Отключаем LAN интерфейс TMG01
      3.        Поскольку мы его выключили мак NLB кластера приходит с А2 теперь и НР при установлении tcp сессии отправляет запросы на 10.62.7.253 на А2.
      4.       Ну и соответственно все DMZ интерфейсы мы видим.
      5.       Все корректно, NLB не теряем
    2. Вариант2.  Мы отрубаем на П1 DMZ интерфейс, но при этом LAN не вырубаем.
      1.        Допустим, на НР мы видим, что мак адрес NLB 10.62.7.253 приходит с А1.
      2.       На НРах прописан статический маршрут, сеть 10.62.1.0 заруливается на 10.62.7.253
      3.        Пингуем TMG02 интерфейс DMZ 10.62.1.252
      4.       Пакет доходит до НР, НР знает что его нужно зарулить на 10.62.7.253 и знает, что 10.63.7.253 у нее на А1, т.е. сессия устанавливается с TMG01 и пинг 10.62.1.252 идет именно через него.
      5.       В данной ситуации мы отключаем TMG01 DMZ 10.62.1.251, и теряем 10.62.1.253, 10.62.1.252
      6.         Так происходит потому, что НР пакеты на 10.62.1.252 отправляет на 7.253 на А1, т.е. на TMG01, а на нем не доступен интерфейс DMZ. Ключевой момент в том, что НР отправляя пакеты в DMZ видит, что 7.253 доступен на А1 и отправляет туда – TMG01 с недоступным DMZ.
      7.        И так будет до тех пор, пока НР не узнает, что 7.253 у нее приходит с порта А2, а этого не произойдет пока не отключится интерфейс LAN на TMG01.
      8.       Теперь мы выключаем LAN интерфейс на TMG01
      9.          НР по прежнему считает, что мак адрес LAN NLB приходит с А1, до тех пор пока у нее не обновится таблица ARP (по умолчанию 20 минут). И замечательно отправляет запросы DMZ и LAN в порт А1, а там некому ответить – оба интерфейса на TMG01 выключены.
      10.         Делаем на НР время старения АРП записей – 1 минуту.
      11.        Через 1 минуту НР узнает, что мак LAN NLB прилетает с А2 и начинает слать запросы DMZ и LAN на А2, где у нас TMG02 с живыми интерфейсами LAN и DMZ
      12.          Соответственно оба NLB LAN и DMZ становятся доступными.
    3. Зачем отключать проверку спуфинга на ТМГ
      1.        Из-за статического маршрута на HP, допустим мы пингаем П2 TMG02 DMZ 10.62.1.252 (который имеет второй адрес НЛБ 10.62.1.253) в то время как НР знает, что 10.62.7.253 у нее на А1 П1.
      2.  Получается, что сессия с 10.62.1.252 устанавливается, через TMG01 у которого интерфейс DMZ имеет два адреса 10.62.1.251 и 10.62.1.253, т.е. сессия устанавливается с TMG01. 

    • Помечено в качестве ответа Aleksey Ozerov 8 августа 2013 г. 12:18
    8 августа 2013 г. 12:18