» Microsoft ISA Server 2006/2004/2000 & TMG/UAG (Часть 4)

Paromshick, а кофе не заваренным вроде не вкусно пить ...

Собственно получается что моя "задача" по моим ощущениям, в перпендикулярном пространстве (такое наверное есть) относительно "обычного" понимания для чего и/или как работает Tmg.

Есть W2008R2 с Tmg, с одним активным интерфейсом (2 есть, но выключен) .
Есть локальная сеть "С" типа клиентами Win XP/7 без Tmg клиентов.

Пока Tmg работает как firewall (потому как 2 lan - down) , потом может быть будет как еще router/Nat.

Вот откуда "перпендикулярность пространства" - Tmg в большинстве случаев (наверное) рассматривается как скажем так - шлюз со всеми вытекающими, а у меня он выполняет роль firewall сервера.
Поэтому "переброс" пакетов между интерфейсами не интересует, не рассматривается и не нужен.

Кроме того, интересует только Tmg, switch'и не интересуют, потому что нужный функционал обеспечивает именно сервер, на котором Tmg, работающий как firewall; кстати switch у меня пропускают broadcast.

Нужный функционал - это создание "листов просмотра" компьютеров локальной сети - network neighborhood browsing list.
Самый "базовый" вариант его "наполнения" - direct broadcast - пакеты по одному или двум из Udp портов на 192.168.0.255.
Это делает сервер/клиенты, вот почему switch не причем (маршрутизатор тем более, речь о сети "внутри" себя) .

Кстати, еще один случай "нужных" broadcast - dhcp сервер/клиенты (при этом broadcast тоже используется) .

Сейчас по журналу в on-line, например, есть сообщение, что:
Служба межсетевого экрана:
Состояние: Широковещательный пакет был удален политикой Forefront TMG.
Источник: Локальный компьютер (ip server)
Назначение: Internal (192.168.0.255)
Ошибка: 0xc0040025 FWX_E_BROADCAST_PACKET_DROPPED
У меня 192.168.0.255 в Internal.

Вопрос в том, как сделать, чтобы Tmg не "мешал" отправке исходящих broadcast пакетов и приемке broadcast входящих пакетов ?

Кофе просто не пью, я чайный чел.
Насколько я понял, на сервере с TMG расположен некий сервис, которому надо слать бродкасты в сеть и получать на них ответ...
Обычно, трафик от\на компьютер с TMG регулируется тн системной политикой. Насколько я помню, в нее нельзя подсунуть пользовательский протокол или создать пользовательское правило. DHCP уже зашит в системную политику.
Можно попробовать создать правило FW разрешающее нужный трафик.

Цитата:

Насколько я понял, на сервере с TMG расположен некий сервис, которому надо слать бродкасты в сеть и получать на них ответ...

И плюс принимать broadcast' ы клиентов сети.
Пробовал и отдельно правило с отдельно 192.168.0.255 и 255.255.255.255.
Ни фига.

Читал, везде, где написано, что по умолчанию tmg "рубит" broadcast.

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

Vxd2000
Настройки правила делали по аналогии с DHCP? Там два правила на запрос и на ответ, при этом меняются направления, ну и порты.
Насчет недокументированных параметров... Таковых не знаю

Vxd2000
вы уж извините, что вторгаюсь, но вам бы посмотреть на предмет поднятия винс (нетбиос).

по англ. нет возможности.

Vxd2000

И в какой же это вселенной TMG с одним интерфейсом - Firewall ? С одним интерфейсом - это режим Hork Mode, в котором он может быть прямым или реверсивным прокси.

Цитата:

Настройки правила делали по аналогии с DHCP? Там два правила на запрос и на ответ, при этом меняются направления, ну и порты.

Даже все открывал.


Цитата:

И в какой же это вселенной TMG с одним интерфейсом - Firewall ? С одним интерфейсом - это режим Hork Mode, в котором он может быть прямым или реверсивным прокси.

Tmg - во всех (наверное) вселенных Firewall, а Hork Mode - это его один из режимов (role) функционирования, как и front-end and back-end firewall roles. Не так ли.

В моей он точно работает как firewall - блокирует что надо и пропускает что надо, акромя broadcast и multicast. То есть, помимо прочего, разграничивает доступ к серверу из Lan, от Lan клиентов (этот сервер в Lan) . Периметралный firewall другой.

Но мой post - был не об обсуждении firewall это или нет, или его возможных ролей, а о том, как сделать "пропуск" broadcast (причем блокируются исходящие, по log' ам самого Tmg) . Если знаете, подскажите.



Цитата:

ы уж извините, что вторгаюсь, но вам бы посмотреть на предмет поднятия винс (нетбиос)

Если конструктивно, так wellcome.
Тут есть одна "толстость" и одна "тонкость" : "толсость" заключается в том, что не все клиенты у меня Wins (делать Wins их "политически" не получится) ; а "тонкость" - Wins - это разрешение имен (а-ля Dns для NetBios) , а речь идет о составлении списков просмотра - browsing list.
Это несколько иное. Хотя "собирание" может списка базироваться на разрешении имен полученных как через Broadcast, так и через Wins,
Есть такой случай, когда NetBios имена спокойно разрешаются (по NetBios имени получаем Ip, и наоборот) , а в списке сетевого окружения данной станции (компьютера) нет.

Вот сейчас такая ситуация:
после перезагрузки сервера (выставлял его NodeType = 1) , все всё видят - сервер клиентов, клиенты сервер и друг друга, после какого-то времени, сервер и клиенты в сетевом окружении сервера же видны, но в сетевом окружении клиентов сервер не виден, а клиенты видны, хотя имя сервера "разрешается" .

Посмотрел на клиенте WireShark' ом: есть пакеты src=server IP, dst= 192.168.0.255
Странно, Tmg показывает, что для пакета src=server IP, dst= 192.168.0.255 "Широковещательный пакет был удален политикой Forefront TMG. " , 0xc0040025, FWX_E_BROADCAST_PACKET_DROPPED.

Vxd2000

Firewall - это 2 интерфейса. 1 - прокси. Это к конструктиву. Что у клиентов является шлюзом на интерфейсе ?

Firewall - это когда инициатор трафика не у нас, proxy - это когда инициатор трафика у нас. Publishing энд Access рулез
И когда у TMG один интерфейс, он не могёт создавать правила публикации, то есть остаётся только прокси

Первый вопрос на котором многие сыпятся, это какое минимальное количество сетевых интерфейсов должно быть у сетевого экрана.
Правильный ответ - один.
Ибо ничто не мешает создать на одном сетевом интерфейсе несколько сетей. Между несколькими сетями можно настраивать правила разного типа и порядка.
Прокси это вообще иное, ибо протокол куда выше IP. На два уровня, ЕМНИП.
Но вся эта теория нисколько не помогает Vxd2000. Вопроз узко-специальный по теме конкретного продукта -- разрешить bradcast от localhost в некоем направлении (в любом случае от localhost), по произвольному, пользовательскому, протоколу.
Вопрос к Vxd2000. Нельзя ли научить ваш софт бродкастить по протоколу, уже вшитому в системные политики, но неиспользуемому? Тот же DHCP не нужен же при статике. А TMG по барабану, какой демон там слушает, DHCP клиент ли (отключить его нафиг) или самописный.

Li_Support_Ltd, когда два интерфейса - это уже Router.
Взять тот же "Кашперовский" - там есть и сетевой экран (персональный, рабтоает с 1 интерфейсом) .
Li_Support_Ltd, Hunta, если не сложно, поместите ссылки, где есть определение firewall/proxy, указанный вами обоими.

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD

Есть эпизод: "...Основной задачей сетевого экрана является защита сети или отдельных её узлов от несанкционированного доступа..."

Но это, как писал ранее, к моему вопросу отношения не имеет.
Для меня он останется firewall' ом, хоть с 1-м, хоть с 2-мя интерфейсами, потому что то он "защищает" (есть правила фильтрации) и потому что относительно самого сервера (с tmg) internal является внешней, то есть инициатор трафика не "в сервере" , а в internal.



Цитата:

Ибо ничто не мешает создать на одном сетевом интерфейсе несколько сетей. Между несколькими сетями можно настраивать правила разного типа и порядка.
Прокси это вообще иное, ибо протокол куда выше IP. На два уровня, ЕМНИП.

Совершенно согласен с 1 утверждением. Насчет proxy частично согласен.

Все, дискутировать на предмет названия/назначения (роли) Tmg не вижу смысла в рамках моего вопроса - это просто "засорять" тему.

Теперь собственно к моему вопросу.


Цитата:

Что у клиентов является шлюзом на интерфейсе ?

А какая разница ??
В контексте моего вопроса все равно какой шлюз указан у клиентов.



Цитата:

разрешить bradcast от localhost в некоем направлении (в любом случае от localhost), по произвольному, пользовательскому, протоколу.

Совершенно правильно.

Даже еще более "жестче" сформулирую его.
Как, официальными - документированными или не документированными способами разрешить хотя бы исходящий broadcast на dest IP = 192.168.0.255 (сеть С типа) от LocalHost в Internal для Udp протокола, NetBios 137, 138 портов ?
Не официальный - это patch fweng.sys драйвера.
Уже начинаю рассматривать и этот вариант.

Paromshick, перечитав кучу источников по Tmg, пришел к выводу, что ему по "барабану" какой протокол (обычно broadcast только по Udp) и какой порт, но по умолчанию Tmg не разрешает как broadcst, так и multicast пакеты.
Так посчитал #$!@% Microsoft, что не нужны они никому, кто пользуется Tmg.
было бы лучше сделать "регулируемыми" .
Предполагал вначале, что "рубятся" только входящие (от клиентов из lan) , это еще можно понять, но на фига запрещать исходящие broadcast.

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

Судя по всему как раз "не пропуск" исходящих broadcast...

К сожалению, на другие протоколы NetBios не "перевесить" .

Кстати, такая история с любыми портами, с broadcast - "рубит" Tmg.

Вот был еще вариант какого-то registry недокументированного параметра, пока не нашел.

Самое интересно, пакет на 255.255.255.255 не "подпадает" под ошибку, которая выдается при 192.168.0.255.
Сделал предположение, что проверяется последний октет dest IP, и если он = 255, на фиг.
Вот и надо пропатчить драйвер fweng.sys, чтобы убрать эту проверку (отключить) , чтобы пакет обрабатывался не "встроенными" правилами (даже не системными, а "вшитыми" скорее всего в драйвер) .

Других вариантов пока не вижу.

Net Broadcast, All Broadcast... Запутаешься.
Не особо помню, но нетбиос включается точно, без всяких патчей. Будет под рукой интерфейс погляжу, пока что помню, что это в системных политиках. Вроде для разрешения имен через нетбиос. Тот же нет бродкаст и выходит.

Paromshick, если найдете решение без patch' a, с меня пенный напиток.
Но системная политика № 5 включена.
Только разрешение NetBios имен работает и browsing частично тоже, только сервера (где Tmg) в browsing list' е нет.

Vxd2000
Пенный напиток это хорошо, но боюсь, что заработать его мне не светит.
Единственное, что пришло в голову, это включить правило номер 20 и на вкладке "Откуда" добавить требуемые компьютеры, набор компьютеров, или целиком сеть. Как удобнее.

Ничего не дало правило 20.

Мною было пропущено, где у вас тут какие правила отображены?
Иса не даст на уровне пользовательск. правил вам работать на разных уровнях протоколов.
Винс - инициализация того же броадкаста (это просто пакет, и не важно кто его инициализирует и что в нем содержится для фперволла), он создан майкрософтом, скажем так продолжением нетбью.
У вас в сети на машинах работают браузеры сети?

bahtey, computer browser включены везде.
Еще раз, Wins - это один из способов предоставления разрешения имен, помимо broadcast.
Да, neighborhood browsing использует разрешение имен, но разрешение имен и составление списка обозревателя не одно и тоже.

Самый простой пример этого - разрешение имени есть, а компьютера с этим именем нет в списке - в сетевом окружении.


Цитата:

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

Вы не правы. У Wins только unicast пакеты (или по крайней мере в большинстве случаев) , кроме того broadcast пакет - это не unicast пакет, и помимо широковещательного адреса у такого пакета есть еще признак broadcast' ости. И Isa, как раз не все равно что в пакете.

Понял так, что broadcast блокирует fweng.sys, так называемой "вшитой" политикой.


Цитата:

Iса не даст на уровне пользовательск. правил вам работать на разных уровнях протоколов.

Скорее, в моем случае, более правильно будет звучать - не даст работать с определенными видами протоколов или пакетов.
Мне и не нужны разные уровни протоколов, 3 уровня будет достаточно.

Если правильно понял вашу фразу.


В итоге, сейчас, сервер с Tmg:
- Wins на этом сервере стоит;
- unicast Udp пакеты по 137, 138 портам "туда-сюда" ходят - есть правила в Isa: LocalHost->Internal и Internal->LocalHost по 137, 138 Udp портам и 139 Tcp порту;
- сейчас в сетевом окружении других компьютеров не видится именно сервер с установленным Tmg;
- но на самом этом сервере он видится;
- на сервере все другие компьютеры видны (как Wins, так и Broadcast клиенты) ;
- на Wins клиенте ситуация такая же;
- ситуация нормализуется после отключения службы и драйвера Tmg и по прошествии минут 5 - 10;
- после последующего включения драйвера и службы Tmg - "полет" нормальный на ~ 1 час.

Скорее всего 2 последних пункта из - за ttl записей сервера в списке окружения, которые "живут" около часа и не обновляются, из - за Isa.

Тут не надо много букаф.
По индустриальном стандарту, IP сущность, прослушивая трафик, в обязательном порядке реагирует на запросы в свой адрес и широковещательные пакеты и, отбрасывая всякие служебные дела, аля заголовки и пр, извлекает полезную нагрузку, и передает её наверх, другой сущности, будь то TCP или UDP или еще кто, которая, в свою очередь решает, что делать. Передать выше, или отвергнуть.
Классика.
В данной ситуации, дело в том, что IP сущность слушает, но пакеты до нее не доходят. Или рубятся перед передачей наверх. Там еще кучка уровней и рубить можно на любом этапе не калеча при этом ни вложенность протоколов, ни ОС в целом. Встраиваясь. Производителю это легко. Что TMG с успехом делает.
Как конкрено реализовано, я не знаю. Системные программеры могли наваять любой гуанокод и подвесить его драйвером куда угодно.
Факт в том, что IP сущность не реагирует на бродкастовый пакет, если смотреть со стороны.

Paromshick
Да нет, у человека лукавая затея.

Введя в режим блокировки сервер, получаем обычного слушателя и создателя пакетов всяких (почти).

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

bahtey
Не понял ни разу.
Допустим, у меня сервер, на котором я подсадил скуль и некое моё самописное приложние. Серверную часть. В приложение я вложил кучу мозгов и времени. Хочу его охранять, помимо прочего и через ТМГ. И получить кучу бабок.
Чтобы клиентская часть увидела сервер, серверу надо получить и обработать бродкаст. ТМГ не дает.
Вопрос. Как сделать так, чтобы дал?
Что, где, когда, зачем и пр. оставим на совести разработчика. Тут скорее всего недоработка, больше, чем уверен.
Ответьте "как"?

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

Цитата:

Факт в том, что IP сущность не реагирует на бродкастовый пакет, если смотреть со стороны.

Как раз наоборот, реагирует, но отрицательно.
Если правильно понял фразу про "IP сущность" .

Все таки у меня в данном случае не "вертикальное видение" - со 2 уровеняя на 3 уровень и так далее, а "горизонтальное" - пришел пакет от LocalHost на ....255. И на 3 уровне Tmg drop (deny) его.

Начал уже "смотреть" драйвер.
Пока не могу понять как драйвер определяет , что пакет именно broadcast.
Наверное IP адрес и netmask, но могу ошибаться, может как последний IP из заданного диапазона.
Хотя пробовал ставить 192.168.0.0 - 192.168.0.100 например, все равно от LocalHost на 192.168.0.255 "рубит" .


Попробовал в качестве Internal сделать 192.186.0.0-192.168.1.255, все равно пакет на 192.168.0.255 "рубит" как broadcast.


Взято было отсюда:
https://social.technet.microsoft.com/Forums/ru-RU/e2bbc834-6955-4b3f-b374-9aaa7dd48235/client-ip-ends-with-255-inaccessible?forum=Forefrontedgegeneral

По исследованиям, получается, что LocalHost - это отдельная виртуальная сеть.

Пропатчил драйвер.

Что надо работает.
Около 5 дней, на Tmg 2010 SP2 пока нормально.

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

P. S.: Жалко SoftIce под x64 Win 2008R2 не работает.

Кстати, у кого-нибудь есть проблема доступа к клиентам из сервера за Tmg по NetBios - TCP 139 и TCP 445 портам ?
Достаточно много проходит с ввода имени/пароля до "показывания" ресурсов - "расшаренных" папок.
Иногда ошибка что нет прав доступа к ресурсам, иногда "заходит" только со 2 или 3 раза.

На сервер клиенты "заходят" "влет" .

Речь о "1-м" соединении , нет никаких соединений по этим протоколам / портам по net use.
Если соединение "ок" , то все нормально.

Хотя это может быть связано не с Tmg, а с Firewall "слоем" :
https://ask.wireshark.org/questions/16770/server-2008-send-rst-packet
https://msdn.microsoft.com/en-us/library/ff720058.aspx

Народ, у кого есть утилитка ISATpre? Весь интернет перерыл, на привычных местах нет! Выручайте! mpakpm@gmail.com

Народ подскажите возможно ли с помощью продуктов UAG или TMG распределить интернет трафик в доменной сети? Работал с КФВ керио, нужно ограничить н количество юзверей/груп по скорости Интернета что б не все жрали.
Еще правильно ли я считаю сервер где установлен TMG/UAG не вводить в домен, то есть что б фаервол находился не в доменной сети.

cRYSMAS
введя в домен упростишь возможность авторизации трафика по доменным юзерам

Цитата:

введя в домен упростишь возможность авторизации трафика по доменным юзерам

а это не ослабит защиту? тобиш если взломают UAG то сразу попадут в доменную сеть что не желательно...
так все же трафик считается в TMG ?именно Интернет трафик?

cRYSMAS
сама иса/тмг не дает такой возможности.нужен сторонний софт.

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

Не знаю, откуда взялась эта басня, но TMG вполне понимает группы AD и может по ним авторизовать на прокси. НАТ же по умолчанию закрыт.
Другое дело, что надо нарЕзать группы на ТМГ и сопоставить их доменным.
А посторонний софт нужен прежде всего для анализа логов. Для чего и нужна авторизация, собственно. Иначе, все в сад НАТ

fly_indiz

Цитата:

введя в домен упростишь возможность авторизации трафика по доменным юзерам

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

Paromshick

Цитата:

что надо нарЕзать группы на ТМГ и сопоставить их доменным

Можно и без этого

Но.
С введением в AD - проще (хотя и менее безопасно)