Winroute.ru

[Zorro]

Что-то опять на форуме огромная куча вопросов, и множество из них связаны с неправильной настройкой Traffic Policy (далее правила) в Kerio Winroute Firewall, собственно поэтому решил еще один опус написать :)

Перед тем, как что-то делать с правилами, необходимо настроить сетевые интерфейсы по-человечески, так что кто не читал статью ПРАВИЛЬНАЯ настройка DNS и сетевых интерфейсов!!!, сделайте это сейчас.

Все ниженаписанное было испробовано на версии KWF 6.2.1, но будет работать и на всех версиях 6.xx, для следующих версий если и будут изменения, то не думаю, что значительные.

Итак, сетевые интерфейсы настроены, Kerio Winroute Firewall установлен, первое, что делаем, заходим в Configuration > Traffic Policy и запускаем Wizard. Даже если до этого вы его уже запускали. Мы же делаем правильно, так?

1. С первым и вторым шагами визарда все понятно, на третьем выбираем внешний сетевой интефейс (Internet Interface, Wizard почти всегда сам определяет его правильно).

2. Далее, шаг четветый, самый важный.
По умолчанию KWF предлагает вариант "Allow access to all services (no limitations)", но! Постоянно сталкиваемся с тем, что такие правила KWF обрабатыват мягко говоря странно, углубляться не будем, кого интересует, может форум почитать, проблемы с сервисом :) ANY сплошь и рядом (вот здесь например -[открыть ссылку] ).

Поэтому выбираем второй вариант, Allow access to the following services only. Неважно, что KWF вам возможно предложит немного не те сервисы, какие вам нужны, но все это можно добавить или убрать позднее.


3. На пятом шаге создаем правила для VPN, те кому они не нужны, могут убрать галки. Но опять же можно это сделать и потом, если не уверены.

4. Шаг 6-й, тоже довольно важный. Здесь создаем правила для тех сервисов, которые должны быть доступы извне, из Интернета. Советую добавить хотя бы парочку сервисов, вам самим потом проще будет увидеть, как строится такое правило.
Например:
сервис KWF Admin на Firewall
сервис RDP на 192.168.0.15


5. Шаг седьмой, естественно включаем NAT, даже кому и не нужно будет (маловероятно конечно), всегда его можно выключить.
На восьмом шаге жмем Finish.

Получается у нас что-то типа того:


Небольшие пояснения для тех, кто мануал не хочет читать.
Правило NAT - в нем собственно те сервисы которым можно ломится в интерет с клиентских машин.
А правило Firewall Traffic - это правило для той машины, на которой KWF стоит.
Красненькие правила ниже - для доступа из Интернета к одноименным сервисам.

В принципе уже работать можно, но ведь нужно KWF немного настроить, поэтому дальше:

6.Правило Local Traffic передвигаем на самый верх, ибо правила обрабатываются сверху вниз и поскольку локальный трафик как правило превалирует над остальным, это позволит снизить нагрузку на шлюз, чтоб он не гнал пакеты от локального трафика через всю таблицу правил.
7. В правиле NAT вместо "Default Outgouing Intrerface" ставим "Internet Interface".

8. В правиле Local Traffic Protocol Inspector отключаем, ставим в None.

9. Из правил NAT и Firewall Traffic убираем ненужные нам сервисы, а нужные соответственно добавляем. Ну например ICQ :) Советую думать над тем, что вы добавляете и удаляете.

10. Иногда для некоторых сервисов требуется отдельное правило, потому что вместе с остальными начинаются непонятные глюки. Ну и отследить как оно отрабатывает проще конечно, поставив логгирование этого правила.

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


Несколько примечаний:

11. Если хотите, чтобы с клиентских компьютеров можно было пинговать внешние адреса, то добавьте сервис Ping в правило NAT.

12. Eсли не используете VPN совсем, отключите VPN-сервер (Configuration > Interfaces > VPN Server правой кнопкой > Edit > убрать галку Enable VPN Server).
Еще можно отключить интерфейс Kerio VPN.

13. Если используете Parent proxy, добавьте в правило Firewall Traffic соответствующий порт (Если стандартный 3128, то можно добавить сервис HTTP Proxy). А из правила NAT тогда нужно убать как минимум HTTP и HTTPS сервисы.

14. Если доступ в Интернет нужно дать какой-то группе пользователей или IP-адресов, то создаете правило, подобное NAT, только в качестве источника у него не Local Interface, а ваша группа.


Ниже более-менее похожий на реальность (мою естественно :) , но не совсем) пример.

Пример.
Задача: раздать интернет всем компам из сети, используя непрозрачный прокси, разрешить ICQ и FTP избранным группам, а скачивание почты по POP3 всем. Запретить отсылать письма напрямую в Интернет, только через почтовик. Сделать доступ к этому компьютеру из интернета. Ну и учесть примечания естественно.
Вот сразу правила готовые:


Краткие пояснения по правилам:
Local Traffic - на самый верх, как и собирались.
NTP Traffic - правило для синхронизации сервера времени (192.168.0.100) с источниками точного времени в интернете.
ICQ Traffic - правило, разрешающее группе пользователей "Allow ICQ Group" пользоваться аськой.
FTP Traffic - правило, разрешающее группе пользователей "Allow FTP Group" скачивать файлы с FTP-серверов.
NAT for all - мало от НАТа осталось (мы же через прокси ходим в интернет) только free mail и ping интернета всем пользователям сети разрешен.
Firewall Traffic - с этим все понятно, разрешенные сервисы для фаервола. Обратите внимание, что сюда добавлен сервис SMTP (в случае, если почтовик находится не на том же компьютере, что и винроут, нужно сделать отдельное правило) и порт 3128 для парент прокси.
Service Ping - правило, нужное для того, чтобы пинговать наш сервер снаружи.
Remote Admin - правило для доступа снаружи к консоли KWF и KMS, к веб-интерфейсу их же.
Service Kerio VPN - правило для доступа снаружи клиентов Kerio VPN.
Service Win VPN - правило для доступа снаружи клиентов родного виндового VPN
Service RDP - правило для доступа снаружи клиентов виндового терминала (но лучше через VPN).

В принципе все, по мере сил своих и замечаний гуру буду исправлять и дополнять эту статью.

Исправления и дополнения принимаются ;)

ВНИМАНИЕ НАЧИНАЮЩИМ!
Если у вас что-то не работает, пожалуйста не задавайте ваш вопрос в этой теме, а создайте отдельную.

[Al]

Вот мой ТП (один из, немного урезанный) - совершенно рабочий - в одной конторе



Суть: Стоит авторизация через ВЕБ, поэтому HTTP сервис отдельно не отгораживается конструкцией Authenticated Users - KWF сам запрашивает авторизацию при доступе по этому протоколу.

ISS - отключен
KWF Admin Remote Access - говорящее название - правила удаленного доступа с помощью консоли управления КВФ
KMS Admin Remote Access - не менее говорящее - удаленный доступ консолью до mailserver внутри LAN
KMS HTTP/HTTPS Remote Access - правила для портмаппинга на ВЕБ-интерфейс mailserver'а с наружи внутрь сети
Remote Web-cam - смотреть за юзверями (стоит программка как веб-сервис)
Intranet WEB-server - http- сервер внутри сети - доступ с наружи
Intranet RAdmin - доступ к каждому компу в сети с наружи РАдмином (сколько компов - столько и правил - порезано ))) )
Intranet MySql - Доступ к Mysql серверу с наружи
Клиентбанки - на машине с КВФ стоят - все понятно
DynDNS - программа для обновления ИП динамического
KMS through NAT - Доступ мейлсервера наружу для ПОП3 и СМТП - без авторизации (вот в последнее время думаю что нужно через HTTP Policy сделать - не однозначно почему-то может работать когда кто-то авторизовался - что странно)
Auth. Non-http NAT - правило куда выделены сервисы для работы с которыми пользователям сети нужно пройти авторизацию - обязательно
NAT - все что осталось от безнаказанного НАТа - ДНС %-)
Auth Non-http FW - правило куда выделены сервисы для работы с которыми пользователям сети нужно пройти авторизацию - обязательно - для тех кто за компом с КВФ сидит (к сожалению есть такое)
Firewall Traffic - Тоже только ДНС

[Zorro]

Al, ну да, пожалуй мне тоже нужно добавить конретный пример.

[Boieng]

Предлагается еще задвинуть на самый верх правило для локального трафика (local trafic) ибо правила обрабатываются сверху вниз и поскольку локальный трафик как правило превалирует над остальным, это позволит снизить нагрузку на шлюз, чтоб он не гнал пакеты от локального трафика через всю таблицу правил. И я бы включил логгирование пакетов на default rule, чтоб видеть какие пакеты шлюз не пропустил наружу, это отчасти поможет в диагностикe, если вдруг с локалкой что-то случится.

[Zeus33]

спасибо за правлиа Al они меня выручили

[Al]

Boieng, на счет локального трафика согласен - передвину. На счет лога default rule - не вижу смысла - только в спец случаях, когда выявляю нужный сет портов и диагностики - на время. Иначе фильтер лог перельет через край. Тем более у меня там раз в 3 секунды широковещалка с внешнего интерфейса только по 520 порту капает.... Не интересно. А так как с внехи меня еще роутер отгораживает, то не парюсь.

[Al]

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

[ua9mub]

[Al]

ua9mub, поправил