Vxd2000
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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, чтобы убрать эту проверку (отключить) , чтобы пакет обрабатывался не "встроенными" правилами (даже не системными, а "вшитыми" скорее всего в драйвер) .
Других вариантов пока не вижу. |
Всего записей: 1134 | Зарегистр. 14-11-2002 | Отправлено: 21:43 27-08-2015 | Исправлено: Vxd2000, 21:44 27-08-2015 |
|
