Отказ от ответственности Журнал Заметки Галерея

Кое-что об IGMP и NAT в Windows 2008 R2 [15.09.2011]

Все началось с попытки заставить Windows 2008 R2 с установленным Forefront TMG 2010 пропускать IPTV в локальную сеть, сидящую за NAT-ом.

Все сказанное далее относится к TMG с ServicePack 1. Как показала практика установка SP2 помимо ранее обнаруженных проблем (note111014.htm), так же окончательно блокирует прохождение multicast трафика даже на внешнем интерфейсе. Впрочем, надо понимать так, что с точки зрения майкрософта это вовсе не проблемы, а так и задумывалось. Просто после первого сервиспака не получилось.

Небольшое отступление для тех, кто хочет просто настроить IPTV в локальную сеть и не вникать в подробности. Забудьте про multicast за NAT-ом для Windows 2008. На шлюзе нужно установить UDP-to-HTTP Прокси и не морочить себе голову. Оно, как правило, идет в комплекте с IPTV плеером. Если в инсталляции нет такого компонента, то его легко найти в интернете как отдельное приложение. После установки запустите UDP-to-HTTP Прокси, выберите внешний и внутренний интерфейс и нажмите «Запускать как сервис/Установить». На клиентских машинах в качестве интерфейса нужно указать внутренний адрес сервера и через двоеточие порт UDP-to-HTTP Прокси. Все. Если возникли проблемы, добро пожаловать в google.

UDP-to-HTTP Прокси

Для остальных продолжим. Коротко о настройках. Предполагается, что Forefront TMG уже установлен и настроен, или на трансляцию внутренних адресов во внешний, или на маршрутизацию. В консоли «Маршрутизация и удаленный доступ» в IPv4 добавляем протокол маршрутизации IGMP. Добавляем в него два интерфейса. Внешний устанавливаем как IGMP-Прокси, внутренний как IGMP-маршрутизатор. Версия протокола IGMP, как показали дальнейшие опыты, в нашем случае значения не имеет.

Маршрутизация и удаленный доступ

В Forefront TMG добавляем правило разрешающее UDP пакеты с нужным номером порта из External во все сети. На самом деле при создании правила достаточно указать Direction только Send, так как multicast пакеты идут в одну сторону и UDP ответов приложение IPTV не генерирует. В некоторых статьях почему-то требуют Send Recv.

Поскольку для управления UDP multicast потоком используется IGMP, необходимо добавить правило пропускающее IGMP трафик. Для этого создается User-defined протокол ip-level с номером 2 и разрешается во всех направлениях. Угрозы для безопасности от этого практически нет, так как IGMP не маршрутизируется в глобальных сетях обычным образом и шанс, что его использует троян для отправки приватной информации, ничтожно мал. В этом смысле использование ICMP (по нему ping работает, например) и то значительно практичнее.

IGMP в Forefront TMG

После выполненных настроек IPTV начинает работать, но только на сервере. ВНИМАНИЕ! В IPTV плеере в настройках интерфейс для работы по умолчанию выбран как «Авто». В случае если плеер ничего не показывает, выберите вместо «Авто» адрес внешнего интерфейса.

Настройки IPTV

Если же запустить плеер из локалки, то ничего не работает. Анализ пакетов с помощью Wireshark показывает, что IGMP функционирует нормально и на внешний интерфейс приходит UDP трафик согласно с выбранным каналом вещания. Но во внутреннюю сеть multicast не попадает.

После анализа логов Forefront TMG удалось выяснить, что все multicast пакеты отбрасываются с ошибкой FWX_E_BROADCAST_PACKET_DROPPED (A broadcast packet was dropped by the Forefront TMG policy). И не удается найти настраиваемых системных или пользовательских правил, которыми это поведение можно было бы изменить. Так же не получилось найти какой-нибудь ключик реестра, для отключения данной политики.

В сети есть ссылка, где сказано как настроить multicast для ISA 2004/2006 (это прежнее название Forefront TMG) с оговоркой, что в будущих версиях ISA возможно лазейку закроют. Видимо закрыли. При этом надо обратить внимание, что там речь идет про настройку, когда локалка маршрутизируется в внешнюю сеть. Т.е. трансляция адресов (NAT) должна быть отключена).

Учитывая, что встроенный брандмауэр windows 2008 позволяет настраивать защиту в чем-то даже гибче, было решено продолжить эксперименты без TMG. В предыдущих серверных ОС обойтись без дополнительного софта, при настройке защищенного доступа в интернет, было трудно. Начиная с windows 2008 ситуация поменялась. Преимущества, которые дает Forefront TMG уже не столь значительные. И если конфигурация сетей не сложная, а фильтрация по содержимому и некоторые другие навороты не нужны, то вполне можно обойтись встроенными средствами. Плюс меньше нагрузки на процессор и оперативку.

Если вдруг решите удалить Forefront TMG, обратите внимание на следующее. После удаления, служба NAT в службе «Маршрутизация и удаленный доступ» отказывается работать. Причина в том, что при установке, TMG затирает ссылку на драйвер ipnat.sys надписью /Path overridden by Forefront TMG - do not edit/. А после удаления себя любимого, не возвращает ее на место. Так что проверьте в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IPNAT параметр ImagePath дожен быть system32\DRIVERS\ipnat.sys, а параметр Start - 0x00000003. И еще желательно удалить и заново (после перезагрузки) установить роль «Службы политики сети и доступа». Это очистит некоторые ключи в регистре, в частности службы tcpip.

ipnat в regedit

Далее запускаем службу «Маршрутизация и удаленный доступ», добавляем IGMP и интерфейсы как сказано в начале. В брандмауэр - IGMP для всех и входящий порт UDP, или просто на время его отключаем. Перезапускаем службу. IPTV в локалке заработало.

Все бы хорошо, но при попытке добавить в NAT внешний интерфейс с включенной трансляцией адресов, multicast внутрь сети опять перестает проходить.

Как выяснилось из дальнейших исследований, в windows 2003 вопрос решался добавлением параметра AllowInboundNonUnicastTraffic в ключе регистра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\IPNAT\Parameters. В windows 2008 он не работает, хотя при просмотре файла ipnat.sys в шестнадцатеричном редакторе эта строчка в нем есть. Кроме того размер файла ipnat.sys от windows 2003 близок по размеру и очень похож по составу и расположению строковых значений (говорит о там, что исходник скорее всего один). Различие в том, что у драйвера для windows 2008 есть набор строк начинающихся с fwp… Это фунции предназначенные для работы с windows filtering platform, новым механизмом обработки сетевого трафика. Видимо дорабатывая драйвер для новой платформы, разработчики, толи забыли, толи умышленно отключили AllowInboundNonUnicastTraffic. Найти подтверждающую или опровергающую это предположение информацию не удалось. Поиск других ключей или способов заставить работать эти два протокола вместе ни к чему не привели.

И еще. Используя netsh удалось выяснить, что драйвер NAT регистрирует callout на внешнем интерфейсе и перехватывает все пакеты. Обратно в стек он возвращает только то, что считает нужным. В данном случае multicast судя по всему отбрасывается. Возможно, так и было задумано.

Решений этой проблемы могло бы быть несколько. Можно было подправить драйвер NAT. Можно было написать свой фильтр, который будет перехватывать multicast до NAT-а и переправлять во внутреннюю сеть. Оба варианта имеют тот недостаток, что для x64 придётся подписывать драйвер, да и возни много. Можно было бы сделать user-mode приложение, с использованием WFP или winsock. Но поскольку есть UDP-to-HTTP Прокси, все это имеет мало смысла. Остается только признать, что встроенными средствами Windows 2008, multicast одновременно с NAT запустить в локалку не получается.

И раз уж речь зашла о загадках, то есть еще одна проблема, которая связана со службой маршрутизации и удаленного доступа и windows filtering platform. Как известно после инсталяции Windows 2008 по умолчанию запускается протокол IPv6 и вместе с ним устанавливаются еще несколько виртуальных адаптеров, которые дают возможность наладить передачу трафика IPv6 через сети IPv4. Один из них 6to4 при наличии внешнего IP адреса автоматически получает правильную конфигурацию и при поддержке со стороны интернет провайдера сразу может работать. Это можно проверить с помощью ping ipv6.google.com. Этот адрес имеет AAAA DNS запись и не имеет A, поэтому ping автоматически выбирает ключ -6. Поддержку 6to4 у провайдера можно проверить с помощью ping 192.88.99.1. Остается только настроить раздачу полученной подсети /64 в локалку и IPv6 работает.

Но и тут не обошлось без проблем. При попытке в службе Маршрутизации и удаленного доступа установить любую из галочек IPv4-сервер удаленного достпа или IPv6-сервер удаленного доступа, как ping ipv6.google.com перестает проходить. Каким образом включение и отключение удаленного доступа влияет на TCP/IP стек непонятно.

RAS в Маршрутизации и Удаленном доступе

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

 
Реклама

www.alvis.com.ua
Котлы, водонагреватели, радиаторы и все необходимое для их установки

m-t.com.ua
Плитка, сантехника, низкие цены

www.rdsrv.org
Программа для удаленного администрирования компьютеров

журнал - заметки - галерея Все материалы на сайте являются собственностью автора © kuzmin@it.kharkov.ua +380504010794