Разграничение доступа туннелируемых сетей

[k.shmakov@rasse.ru]

Коллеги, добрый день!

Есть две офиса. В каждом есть координатор HW1000 версии 3 и две сети (сеть А, сеть Б), подключенные к разным интерфейсам координаторов. Обе сети туннелируются.

Нужно разграничить доступ между сетями, т.е. чтобы из сетей А нельзя было попасть в сети Б. Можно ли так сделать в 3 версии?

[Sergeyy]

Фильтрами туннелируемых пакетов. Убить фильтр по умолчанию и прописать нужные правила. По умолчанию там все разрешено для туннелируемых узлов.

[k.shmakov@rasse.ru]

В фильтрах туннелируемых пакетов нельзя прописать правило, чтобы и в поле "from" и в поле "to" был IP адрес, обязательно нужно указывать ID узла. Т.е. можно из одной сети запретить доступ ко ВСЕМ сетям в другом офисе, а надо запретить только к одной.

[zero]

50 минут назад, k.shmakov@rasse.ru сказал:

две сети (сеть А, сеть Б), подключенные к разным интерфейсам координаторов

 

50 минут назад, k.shmakov@rasse.ru сказал:

Нужно разграничить доступ между сетями, т.е. чтобы из сетей А нельзя было попасть в сети Б

  Тут играют транзитные, а не туннелируемые фильтры. Так как туннелируемым трафик становится, когда его надо шифровать, а между сетями А и Б этого делать не нужно.

[k.shmakov@rasse.ru]

Транзитным фильтром можно запретить трафик из сети А1 в сеть Б1 (в первом офисе). А вот трафик из А1 (в первом офисе) в Б2 (во втором офисе) будет уже туннелируемым, транзитный фильтр на него не будет работать. Вот как запретить из А1 в Б2 (и из Б1 в А2)?

[zero]

В актуальной версии прошивки ПАК можно задать и для источника и для назначения ip-адрес в фильтре туннелируемых ресурсов.

Если версия прошивки более старая, то можно было прописать правило вида <id удалённого коордиатора> to <ip-адреса A1> pass, <id удалённого коордиатора> to <ip-адреса А2> drop и далее по аналогии. Нельзя было запретить конкретному туннелю ходить на другой туннель, но Вам это и не нужно.

 

[w03zd8rc]

В 31.08.2018 в 14:27, k.shmakov@rasse.ru сказал:

В фильтрах туннелируемых пакетов нельзя прописать правило, чтобы и в поле "from" и в поле "to" был IP адрес, обязательно нужно указывать ID узла. Т.е. можно из одной сети запретить доступ ко ВСЕМ сетям в другом офисе, а надо запретить только к одной.

Присоединяюсь к вопросу. Такая же проблема.

Суть изложу, на всякий случай, своими словами:

Есть сеть А 192.168.0.0/24 с координатором 0000001A и сеть Б 192.168.1.0/24 с координатором 0000002A

Каждый координатор свою сеть туннелирует. В моём случае есть доступ к координатору сети А (координатор сети Б не мой, связь ч/з межсетевое).

Задача из сети Б пропускать только определённые адреса, например дать доступ 192.168.1.20 до 192.168.0.40, а остальные не пропускать.

[zero]

7 часов назад, w03zd8rc сказал:

Присоединяюсь к вопросу. Такая же проблема.

Постом Выше Вашего предложено решение. Оно плохое?

 

7 часов назад, w03zd8rc сказал:

Задача из сети Б пропускать только определённые адреса, например дать доступ 192.168.1.20 до 192.168.0.40, а остальные не пропускать.

 Откуда такая маниакальная тяга к блокировке именно по ip-адресу? Она же элементарно обходится и реально ни от чего не защищает. Настаивайте на выдаче "правильным" пользователям ПО ViPNet Client и блочьте их уже по идентификатору, он уникален :)

[Vintik]

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

Откуда такая маниакальная тяга к блокировке именно по ip-адресу? Она же элементарно обходится и реально ни от чего не защищает.

Ну вы предлагаете Клиенты, а это дорого, а где то не применимо (может там всё на Линуксе), и зачем тогда тунели у вас созданы?

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

[zero]

14 часов назад, Vintik сказал:

где то не применимо (может там всё на Линуксе)

Есть же клиент под linux. И даже координатор есть.

 

14 часов назад, Vintik сказал:

зачем тогда тунели у вас созданы? 

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

 

14 часов назад, Vintik сказал:

от таких балбесов как я реально защищает

Поверьте, даже балбесы умеют менять ip-адрес в ОС. Это совсем не сложно. Но если стоит задача защититься только от домохозяек и уборщиц, то вероятно и Випнет не нужен.

  В конечном счёте только Вы сами в состоянии оценить риски принятия той или иной политики и последствия принятия этого решения. В любом случае в актуальной версии 4.2.4 можно укзать ip-адреса в туннелируемых фильтрах, а для более ранних в правиле следует использовать идентификатор координатора.

[Vintik]

5 часов назад, zero сказал:

Есть же клиент под linux. И даже координатор есть.

Тогда предположим у меня такой линукс, где не работает ваш клиент, "Виклинукст" - от такой на пример и ответ от тех.п. будет - работает только на тех 3-5 где мы точно проверяли (где 2-3 из которых на платной основе).

Но в остальном вы конечно правы. Но с другой стороны Винет только IP а дальше НСД будет работать и не переживайте, там враг не пройдёт.

А вы случайно не знаете кстате почему в випнете маски не когда не применяются в тунелях? Там что не пропиши ему получается не важно. хоть /4 хоть /24 

[zero]

14 минут назад, Vintik сказал:

почему в випнете маски не когда не применяются в тунелях? Там что не пропиши ему получается не важно. хоть /4 хоть /24

 Я не проверял никогда такой сценарий. Если возможность задать маску есть (а она есть), но по факту не работает ограничение, то надо писать в ТП, будут разбираться.

[Vintik]

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

Сейчас попробую чуть подробнее и поймёте. Вот на пример я проверял туннель и прописал 10.200.30.5 в ЦУС и отправил на HW 1000 (и на 2000) вер. 4 это было в конце 2017 г .где то (если не ошибаюсь), там только-только стабильная версия вышла, где функция L2OverIP начала наконец то работать больше чем "точка-точка" как было на 3,5.

Но туннель не "L2" - это потом уже... до этого обычный L3 туннель делал (что в итоге потом и сильно не понравилось заказчику т.к. они негодовали "что это за дурость прописывать постоянно по 10-15 сетей, да которые у них ещё как то менялись... потому спасло хоть что "точка-многоточка"  заработала и как раз на из кол-во 15 хватило в притык.

Ну вот проверял туннель L3 и прописал 10.200.30.5 в ЦУС и отправил на HW 1000 (и на 2000) вер. 4 (и до обновления 3,5 тоже самое было).

В итоге у меня на пример хост 10.200.30.5/24 - работает. Т.к. не понимал почему в Випнете нет масок, думаю а что будет если хост 10.200.30.5/8 - работает, а /24 - всё прекрасно... 

Потом уже чтоб окончательно себя "добить" вбил диапазон что то вроде 0.0.0.0 - 255.255.255.255  (там правда где то ошибку выдавал, но может пришлось 254 написать, уже не помню, но мне главное диапазон который будет отлавливать сделал типа "весь IP4" - работает ).

И тогда я подумал - огого. Но конечно так не кто наверно не делает т.к. это не верно и туннелей там же вроде 65535.

Но то что ему всё равно на маски было это наверно такая и была задумка, т.к. в туннели мы их не когда не вводим.