Фильтр для защищенной сети

[sergey.B]

Всем доброго дня!

 

В документации на ПАК «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора» в разделе «Создание сетевого фильтра» приведен пример для создания фильтра защищенной сети, блокирующий все пакеты от защищенного узла с ID 0x1a12000a в сеть ViPNet c ID 0x1b14.

hostname# firewall vpn add src 0x1a12000a dst 0x1b14 drop

Но при попытке создать у себя что-то подобное, естественно со своими ID, у меня появляется сообщение об ошибке

Error: One of the conditions of src/dst must be local or broadcast for dst

которое сообщает, что параметр dst может быть либо local либо broadcast.

И действительно, если я в параметр dst подставляю @local, то правило создается. Даже если другое значение из системных групп объектов, например @allclients, то тоже ошибка.

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

Так что не так? Почему не создаются фильтры с ID в параметре dst?

 

[KostiK2011IT]

Доброго дня!

Напишите правило, которые вы пытаетесь создать - всю команду целиком, которую вводите. Посмотрим, что не так)

Версия ПО на координаторе?

[sergey.B]

Спасибо за отзыв

Проблема оказывается вот в чем! Перед тем как прописывать такие правила в боевую сеть, я решил проверить их на демонстрационном стенде, скаченным с сайта АО «ИнфоТеКС». Так вот, там используется ПО ViPNet Coordinator VA версии 4.5.1. И вот в нем эти команды у меня не работают.

Вот пример:

Coordinator-2# firewall vpn add rule "Drop SSH to Client1" src 0x10e9 dst 0x10e9000f service @SSH drop

Error: One of the conditions of src/dst must be local or broadcast for dst

Пришлось уже проверить на боевой сети. ViPNet Coordinator HW 100 с версией 4.3.2 отработал аналогичную команду без сообщений об ошибке.

 

[KostiK2011IT]

на  демо версии идентификаторы другие, отличные от ваших, вот правило и не пропускается, т.к. тесовый координатор о ваших узлах ничего не знает

[sergey.B]

В комплекте скаченных мною дистрибутивов ключей именно эти идентификаторы.

Вот скриншот во вложении.

[KostiK2011IT]

2 часа назад, sergey.B сказал:

В комплекте скаченных мною дистрибутивов ключей именно эти идентификаторы.

 

Вот скриншот во вложении.

 

Мне не совсем понятен смысл этого фильтра - запретить доступ узлов всей своей сети на клиента из этой же сети по ssh... клиенты могут соединяться друг с другом и мимо координатора и транспорт можно перенастроить соответсвующим образом...

[zero]

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

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

  Вам задачу нужно скорректировать. В клиенте есть свой МЭ, а для централизованной настройки есть Policy Manager.

[sergey.B]

13 минут назад, KostiK2011IT сказал:

Мне не совсем понятен смысл этого фильтра - запретить доступ узлов всей своей сети на клиента из этой же сети по ssh... клиенты могут соединяться друг с другом и мимо координатора и транспорт можно перенастроить соответсвующим образом...

Согласен, клиенты могут соединятся друг с другом напрямую в некоторых случаях, например если они в одной широковещательной доменной сети и mftp можно настроить соответствующим образом. Но согласно схеме стенда Client1  и, например Clien2, располагаются в разных сетях и взаимодействие между ними будет выполняться через Coordinator. Суть фильтра именно в том, чтобы заблокировать любое соединение ssh на клиент через координатор через защищенную сеть.

Да и суть вопроса не в этом. Как будет работать фильтр, это то я и хотел проверить на стенде.

А вопрос «Почему не создаются фильтры с ID в параметре dst?»

Только теперь уже могу добавить уточнение к вопросу «в ПО ViPNet Coordinator VA версии 4.5.1.»

 

[zero]

8 минут назад, sergey.B сказал:

Суть фильтра именно в том, чтобы заблокировать любое соединение ssh на клиент через координатор через защищенную сеть

Координатор эту задачу не решает. Не должен и не может.

[sergey.B]

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

Но это был только пример. А суть моего вопроса от этого не меняется.

Возьмите вот пример из документации по организации канала l2overip

Coordinator-2# firewall vpn add src @any dst @any proto 97 pass

 

Error: One of the conditions of src/dst must be local or broadcast for dst

 

Как видим он тоже не работает, работает только с параметрами local or broadcast

Coordinator-2# firewall vpn add src @any dst @local proto 97 pass

 

Coordinator-2#

 

Coordinator-2# firewall vpn add src @any dst @broadcast proto 97 pass

 

Coordinator-2#

 

 

 

[sergey.B]

23 минуты назад, zero сказал:

Координатор эту задачу не решает. Не должен и не может.

Ещё раз соглашусь с учетом выше сказанного.

Но как быть с примером из документации по организации канала L2?

firewall vpn add src @any dst @any proto 97 pass

[zero]

16 часов назад, sergey.B сказал:

Ещё раз соглашусь с учетом выше сказанного.

Но как быть с примером из документации по организации канала L2?

firewall vpn add src @any dst @any proto 97 pass

На версии 4.3.2 в документации такой пример:

и он работает:

 

На версии 4.5.1 описание уже другое:

и добавление и в src и в dst конкретного идентификатора уже не срабатывает:

 

Вам остаётся проверить документацию на установленную у Вас версию и ее сответствие реальному поведению продукта.

[KostiK2011IT]

15 минут назад, zero сказал:

На версии 4.3.2 в документации такой пример:

и он работает:

 

На версии 4.5.1 описание уже другое:

и добавление и в src и в dst конкретного идентификатора уже не срабатывает:

 

Вам остаётся проверить документацию на установленную у Вас версию и ее сответствие реальному поведению продукта.

при обновление с 4.3.2 на 4.5.1, правила конвертируются автоматически или надо будет править вручную?

[zero]

5 минут назад, KostiK2011IT сказал:

при обновление с 4.3.2 на 4.5.1, правила конвертируются автоматически или надо будет править вручную?

L2 у меня не ломался, т.е. видимо конвертируются, а правил вида идентификатор - идентификатор никогда не было, поэтому ничего не могу сказать по этому поводу.

[sergey.B]

3 часа назад, zero сказал:

Вам остаётся проверить документацию на установленную у Вас версию и ее сответствие реальному поведению продукта.

Я действительно использовал документацию на ПО версии ниже 4.5.1

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

Теперь становиться понятно, почему обязательно значение @local в параметрах src либо в dst. Правила с src @local для исходящих с координатора пакетах, а с dst @local для входящих.

В таком случае все правила по умолчанию в фильтре vpn в которых установлены оба параметры src @any dst @any получается не совсем некорректны. А таких правил там не мало. Логичнее было бы их разбить на два, как в случае с каналом L2. Ведь если случаем удалить такое правило, то его уже не восстановить.

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

Я отлично понимаю, что помимо инкапсулированного пакета, в пришедшем на координатор udp IP-пакете, имеется другая информация о том кому он предназначается. Иначе координатор не смог бы их перенаправлять другим защищенным узлам, в случае если пакет не предназначался ему. Так вот эта часть пакета не шифруется на ключах узлах отправителя и получателя. И я, соответственно, ошибочно полагал, что на основе этой части и происходит фильтрация в vpn.

 

Спасибо за ответы, очень помогли разобраться и продвинуться в этом вопросе.