Полутуннель, Координатор Hw1000

[Отдел ИБ 0]

Доброго времени суток.

Имеется следующая структура сети:

В открытой сети 172.20.0.0/16 находится несколько десятков ПК, среди которых имеется несколько АП с установленным ПО VipNet (перечислены на схеме для интерфейса координатора 172.20.36.99).

С помощью второго интерфейса координатора образована закрытая сеть, состоящая из компьютеров Отделов 2-5. У всех них шлюзом является интерфейс координатора 192.168.36.22, на них не установлено ПО VipNet и они только обмениваются между собой документами. Между интерфейсами координатора настроена маршрутизация.

Некоторым компьютерам из закрытого контура в файле firewall.conf координатора прописаны правила для обмена пакетами по определенным портам с компьютерами из открытой сети без установленного ПО VipNet. Проблем никаких не возникает, поскольку и на ПК из открытого контура, и на ПК из закрытого контура не установлено ПО VipNet и трафик не шифруется.

Теперь возникла необходимость пользователю ClientAP4 из открытой сети (ip-адрес 172.21.73.144) с установленным ПО VipNet Client "забирать" файлы базы 1С с компьютера из закрытой сети (ip-адрес 192.168.25.132), на котором не установлено ПО VipNet. Вначале попробовал прописать разрешающее правило в файерволе координатора, но не помогло, как я понимаю, из-за того, что на одном ПК трафик шифруется, на другом - нет.

В документации к HW1000 нашел схему полутуннеля для подобного случая, но только с 2 координаторами (с. 238 руководства администратора HW1000). Но так и не разобрался до конца для своего случая с одним координатором, какие ip-адреса и где нужно прописать в файле iplir.conf?

Мб кто-нибудь сможет объяснить принцип построения полутуннеля или хотя бы подкинуть какую-нибудь подсказку/идею. Буду очень признателен.

[тшл 0]

IMXO

в Вашем случае в ipilir.conf трогать не нужно ничего, надо попилить firewall.conf, а именно секцию [nat], где и прописать кто и куда будет ходить (подробнее в манах).

Да, не забудьте о последовательности правил (1,2,3,4...) т.е.: 2 - выполнено, 3,4 и.т.д. -- не выполняется

[тшл 0]

1. Проверьте в ЦУСе прописан ли туннель на данный IP.

2. Попробуйте на клиенте (когда он выкл) переимновать ipliradr.do$, он в корне клиента, в ipliradr.doс(как вордовский)

3. Дальше только танцы с бубном....

[AnTonN(c) 0]

Вижу два варианта: либо настройки firewall (при условии, что на ClientAP4 режим безопасности <= 3), либо за полутуннель. Я лично за последнее.

Но прежде чем рекомендовать есть вопрос: 172.21.72.144 не входит в подсеть 172.20.0.0/16. И сам вопрос: это опечатка?

Напишите точные маски подсетей на координаторе и клиентах. И еще вывод in sh ro с координатора не помешает.

[Отдел ИБ 0]

IMXO

в Вашем случае в ipilir.conf трогать не нужно ничего, надо попилить firewall.conf, а именно секцию [nat], где и прописать кто и куда будет ходить (подробнее в манах).

Да, не забудьте о последовательности правил (1,2,3,4...) т.е.: 2 - выполнено, 3,4 и.т.д. -- не выполняется

1. Проверьте в ЦУСе прописан ли туннель на данный IP.

2. Попробуйте на клиенте (когда он выкл) переимновать ipliradr.do$, он в корне клиента, в ipliradr.doс(как вордовский)

3. Дальше только танцы с бубном....

спасибо за советы.

1.1.Я прописывал правила в firewall.conf в разделе [forward], почему именно в [nat]?

2.1.Лицензия не позволяет создавать туннели.

2.2. пункт не совсем понятно для чего?

2.3. не сторонник бубна)

[Отдел ИБ 0]

Вижу два варианта: либо настройки firewall (при условии, что на ClientAP4 режим безопасности <= 3), либо за полутуннель. Я лично за последнее.

Но прежде чем рекомендовать есть вопрос: 172.21.72.144 не входит в подсеть 172.20.0.0/16. И сам вопрос: это опечатка?

Напишите точные маски подсетей на координаторе и клиентах. И еще вывод in sh ro с координатора не помешает.

Спасибо за ответ.

1. ClientAP4 находится во 2 режиме.

2. Насчет адресов немного неправильно выразился. Организация состоит из нескольких корпусов, отстоящих друг от друга на небольшом расстоянии (в пределах 50-100 метров). Соответственно oдна сеть разделена на несколько подсетей, для каждого из корпусов. Корпус с HW1000 и всеми клиентами, кроме ClientAP4, находится в главном корпусе, адрес подсети которого 172.20.0.0/16. В первом корпусе находится непосредственно ClientAP4, подсеть 172.21.0.0/16. Между подсетями должна быть настроена маршрутизация на сервере (не HW1000). Хотя насчет масок все же завтра уточню.

Связь ClientAP4 с координатором есть, он пингует его шлюз 172.20.36.99/16.

3. Таблицу маршрутизации только завтра смогу предоставить после обеда, раньше не получится.

[slavanchuk 0]

1. Действительно, лучше использовать полутуннель, прописав адреса туннелируемых компьютеров через ЦУС.

2. Всё-таки именно топологию сети подробнее опишите, а то из схемы и слов не совсем понятно. Также будем ждать от Вас маршруты.

[Отдел ИБ 0]

Итак, схема приблизительно следующая:

Маршрутизация между подсетями производится маршрутизатором. К маршрутизатору идут управляемые коммутаторы из каждого из корпусов, к которым в свою очередь идут управляемые коммутаторы с каждого из этажей.

HW1000 также подключен к сети через интерфейс 172.20.36.99.

Если что-то упустил, спрашивайте.

Теперь по маршрутизации:

И на всякий случай еще раз айпишники и маски интерфейсов координатора:

[slavanchuk 0]

Насколько я понял:

1. HW1000 подключен к одному из УК в основном корпусе, чтобы закрыть одну подсеть из незащищённых VipNet Client компьютеров.

2. В открытой сети первого корпуса поставили VipNet Client, чтобы получать доступ к защищённой подсети.

То, что пока нужно уточнить:

1. Какие настройки работы через сетевой экран стоят на клиенте? За каким координатором он стоит?

2. Прописаны ли туннели в ЦУСе или вбиты на самом HW1000?

3. Есть ли на маршрутизаторе (не на HW1000) маршрут в данную подсеть?

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

[AnTonN(c) 0]

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

Давайте будем использовать полутуннель. Будем подразумевать, что полутуннель полностью настроен и вопросов в этом плане нет. Клиент проверяет соединение с координатором. Виртуальные подсеть на координаторе 11.0.0.0/24

На 99% процентов координатор видит клиента по виртуальным адресам. А это значит, что на туннелируемый ресурс уйдет пакет с source виртуальным адресом клиента. Пакет, конечно же, дойдет до туннеля, обратный уйдет на шлюз. Какой маршрут выберет шлюз для виртуальной подсети? Конечно свой шлюз, что мимо координатора.

Предложения:

1. Поднять на координаторе nat для подсети 11.0.0.0/24 в адрес координатора.

2. На маршрутизаторе прописать маршрут на 11-ую подсеть через координатор.

[Отдел ИБ 0]

Насколько я понял:

1. HW1000 подключен к одному из УК в основном корпусе, чтобы закрыть одну подсеть из незащищённых VipNet Client компьютеров.

2. В открытой сети первого корпуса поставили VipNet Client, чтобы получать доступ к защищённой подсети.

То, что пока нужно уточнить:

1. Какие настройки работы через сетевой экран стоят на клиенте? За каким координатором он стоит?

2. Прописаны ли туннели в ЦУСе или вбиты на самом HW1000?

3. Есть ли на маршрутизаторе (не на HW1000) маршрут в данную подсеть?

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

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

Давайте будем использовать полутуннель. Будем подразумевать, что полутуннель полностью настроен и вопросов в этом плане нет. Клиент проверяет соединение с координатором. Виртуальные подсеть на координаторе 11.0.0.0/24

На 99% процентов координатор видит клиента по виртуальным адресам. А это значит, что на туннелируемый ресурс уйдет пакет с source виртуальным адресом клиента. Пакет, конечно же, дойдет до туннеля, обратный уйдет на шлюз. Какой маршрут выберет шлюз для виртуальной подсети? Конечно свой шлюз, что мимо координатора.

Предложения:

1. Поднять на координаторе nat для подсети 11.0.0.0/24 в адрес координатора.

2. На маршрутизаторе прописать маршрут на 11-ую подсеть через координатор.

Клиент работает во 2 режиме, все клиенты VipNet организации, включая этого, завязаны на один-единственный координатор HW1000. С клиента AP4 шлюз координатора пингуется, до меня даже уже предыдущий работник прописывал полутуннель с этого клиента до другого компьютера из закрытого контура(192 подсеть), но как конкретно это сделано, я до конца и не понял. С ним связаться нет возможности, больше никто в организации VN не занимается. Мне приходится в экстренном режиме со всем этим разбираться, и вот возникла необходимость прописать связь к компьютеру из закрытого контура от ClientAP4.

Необходимые сведения я Вам предоставлю в случае необходимости. Судя по правилам в файлах iplir.conf и firewall.conf я пришел к следующему: в iplir в блоке настроек для координатора он прописал туннель tunnel = 192.168.0.2-192.168.0.2 to 192.168.0.2-192.168.0.2, маска подсети 16; и в правилах МЭ прописал разрешающее правило от 172.21.73.144 до 192.168.0.2. Возможно я что-то еще упустил, в итоге с ClientAP4 компьютер 192.168.0.2 пингуется.

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

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

Хотелось узнать, что я мог упустить, и если Вам будет несложно, то хотя бы вкратце объясните про записи типа tunnel = ... в файле iplir.conf и вообще про процедуру создания полутуннеля.

Про полутуннели нашел только в приложении к руководству по HW1000, и то для двух координаторов и совсем не описано про tunnel = ..., зачем там пишут один и тот же айпишник и до, и после слова to.

[Отдел ИБ 0]

Сейчас же в дополнение к 192.168.0.2 ClientAP4 должен "поддерживать связь" с 192.168.25.132.

Я прописывал в поле настроек координатора в файле iplir.conf tunnel = 192.168.25.132-192.168.25.132 to 192.168.25.132-192.168.25.132, ну и в файерволе разрешающие правила в обоих направлениях.

[slavanchuk 0]

Два раза пишутся, так как первая часть - это реальные адреса. А вторая часть - это отображение. Можно отобразить туннелируемые компьютеры и в виртуальные адреса.

P.S. А на компьютере с клиентом, туннелируемом компьютере или маршрутизаторе Ваш предшественник ничего не мог написть? Может маршрут где-то прописан был?

[Отдел ИБ 0]

Два раза пишутся, так как первая часть - это реальные адреса. А вторая часть - это отображение. Можно отобразить туннелируемые компьютеры и в виртуальные адреса.

P.S. А на компьютере с клиентом, туннелируемом компьютере или маршрутизаторе Ваш предшественник ничего не мог написть? Может маршрут где-то прописан был?

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

Все-таки, может быть есть рекомендации для того, чтобы прописать компьютер без випнета в полутуннель?

Для моего случая что и где необходимо писать в файле iplir.conf?

IP компьютера с VipNet Client: 172.21.73.144

IP компьютера из закрытого контура без VipNet Client: 192.168.25.132.

[Отдел ИБ 0]

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

Все-таки, может быть есть рекомендации для того, чтобы прописать компьютер без випнета в полутуннель?

Для моего случая что и где необходимо писать в файле iplir.conf?

IP компьютера с VipNet Client: 172.21.73.144

IP компьютера из закрытого контура без VipNet Client: 192.168.25.132.

Вот еще что кстати. В файле firewall.conf правила прописаны в блоке [forward], в документашке к HW1000 сказано, что их нужно прописывать в блоке [tunnel]. У меня в файле конфигурации МЭ такого блока нет, между какими блоками его необходимо прописывать? Я пробовал прописать в конце, он ругается, пишет, что неверная конфигурация.

[slavanchuk 0]

Вроде бы, блок [forward] отвечает за транзитные пакеты. Значит, речь идёт о незащищённом трафике (узел не туннелируется, а маршрутизируется). Вам нужно прописать пакеты именно в tunnel (в том же файле).Туннель, вроде бы, сразу после блока forward.

[Отдел ИБ 0]

Вроде бы, блок [forward] отвечает за транзитные пакеты. Значит, речь идёт о незащищённом трафике (узел не туннелируется, а маршрутизируется). Вам нужно прописать пакеты именно в tunnel (в том же файле).Туннель, вроде бы, сразу после блока forward.

Пробовал прописать блок [tunnel] между каждым из прочих блоков (прописаны ниже), + после него добавлял правило по умолчанию (rule= proto any from any to any pass). Во всех случаях выдает ошибку, что файл firewall.conf сконфигурирован неверно. Отменяю изменения, все нормально.

Ниже набор правил из файла firewall.conf:

[settings]

[antispoof]

antispoof=no

eth0=internal,192.168.36.22/16

eth1=external,anypublic

eth2=internal,10.241.0.4/24

[broadcast]

rule= num 1 proto udp from any:68 to any:67 out pass

rule= num 2 proto udp from any:67 to any:68 in pass

rule= num 3 proto udp from any:137 to any:137 pass

rule= num 4 proto udp from any:138 to any:138 pass

rule= num 5 proto udp from any to any:53 pass

[nat]

rule= num 1 proto tcp,udp from 192.168.0.0/16 to any change src=172.20.36.99:dy$

rule= num 2 proto tcp from any to 172.20.36.99:21 change dst=10.241.0.5:21

rule= num 3 proto tcp from 10.241.0.5/32 to any change src=172.20.36.99:dynamic

[local]

rule= num 1 proto tcp from 172.20.47.224 to 172.20.36.99 pass

rule= num 2 proto tcp from 172.20.36.99 to 172.20.47.224 pass

rule= num 3 proto udp from any:68 to any:67 out pass

rule= num 4 proto udp from any:67 to any:68 in pass

rule= num 5 proto udp from any:137 to any:137 pass

rule= num 6 proto udp from any:138 to any:138 pass

rule= num 7 proto udp from any to any:53 pass

rule= num 12 proto tcp from 10.241.0.5 to any in pass

[forward]

rule= num 1 proto tcp from 10.241.0.5 to 172.20.90.31:12003 pass

rule= num 2 proto tcp from 10.241.0.5 to 172.20.90.32:12003 pass

rule= num 3 proto tcp from 10.241.0.5 to 172.20.36.225:(4668,4673) pass

rule= num 4 proto tcp from 10.241.0.5 to 172.20.36.121:80 pass

rule= num 5 proto tcp from 172.20.90.31 to 10.241.0.5 pass

rule= num 6 proto tcp from 192.168.25.130 to 172.20.48.127:445 pass

rule= num 7 proto tcp from 172.20.48.127 to 192.168.25.130 pass

rule= num 8 proto tcp from (192.168.25.130/16,192.168.20.141/16,192.168.25.141/16) to 172.20.0.11:(25,110) pass

rule= num 9 proto tcp from 172.21.73.144 to 192.168.0.2 pass

rule= num 10 proto tcp from 192.168.0.2 to 172.21.73.144 pass

rule= num 11 proto tcp from 172.20.36.225 to 192.168.25.130-192.168.25.133 pass

rule= num 12 proto tcp from 192.168.25.130-192.168.25.133 to 172.20.36.225 pass

rule= num 13 proto tcp from 192.168.25.132 to 172.20.48.127 pass

rule= num 14 proto tcp from 192.168.10.141 to 172.20.20.20 pass

rule= num 15 proto tcp from 192.168.10.242 to 172.20.20.20 pass

[slavanchuk 0]

Что ещё за правило по умолчанию?! Прописывать нужно в следующем формате:

tunnel= 192.168.100.1-192.168.100.5 to 192.168.100.1-192.168.100.5

[Отдел ИБ 0]

Что ещё за правило по умолчанию?! Прописывать нужно в следующем формате:

tunnel= 192.168.100.1-192.168.100.5 to 192.168.100.1-192.168.100.5

Да, не подумал. Но правило по умолчанию взято из руководства администратору HW1000 (с. 89).

[Отдел ИБ 0]

Да, не подумал. Но правило по умолчанию взято из руководства администратору HW1000 (с. 89).

все равно ругается именно на блок [tunnel]

[slavanchuk 0]

Извиняюсь - действительно ошибся. Данная строка, которую я указал, используется для настройки туннеля, а не для фильтрации туннелируемых ресурсов. Правила для туннелей задаются таким же образом, как и для остальных правил, за исключением того, что нельзя указывать направление соеденения. Ещё одна особенность правил с туннелями - нельзя писать any to any, поскольку здесь мы задаём правила фильтрации между туннелируемыми узлами и ЗАЩИЩЁННЫМИ узлами (не открытыми). Вторая секция вместо any должна содержать anyid (если вы в первой секции также используете any). А в первой секции лучше использовать anyip. Видимо, у Вас в этом была ошибка.

Кстати, а сами туннели-то у Вас прописаны?

[Отдел ИБ 0]

Итак, сделал все вышеописанное. По-прежнему выскакивает та же ошибка.

Вот то, что я прописал в добавленном блоке [tunnel]:

Выскакивает ошибка:

Теперь в фале конфигурации по поводу туннеля. Раньше в блоке параметров координатора было написано:

[id]

id= 0x0570000a

name= ServerM1

filterdefault= pass

ip= 10.241.0.4

ip= 172.20.36.99

ip= 192.168.36.22

tunnel= 192.168.0.2-192.168.0.2 to 192.168.0.2-192.168.0.2

tunnel= 192.168.25.131-192.168.25.131 to 192.168.25.131-192.168.25.131

firewallip= 91.202.255.68

port= 55777

proxyid= 0x00000000

usefirewall= on

fixfirewall= on

virtualip= 10.0.0.1

При этом нормально функционирует туннель между 192.168.0.2 и 172.21.73.144.

После двух туннелей прописал еще один:

tunnel= 192.168.25.132-192.168.25.132 to 192.168.25.132-192.168.25.132

Он предназначен как раз для связи 172.21.73.144 с 192.168.25.132.

Итак, на данный момент 2 проблемы:

1) не добавляется блок [tunnel] в МЭ.

2) правильно ли проделаны действия для настройки туннеля?

[slavanchuk 0]

Итак, на данный момент 2 проблемы:

1) не добавляется блок [tunnel] в МЭ.

2) правильно ли проделаны действия для настройки туннеля?

1. У Вас в синтаксисе ошибка. Уберите первое правило.

2. По настройкам туннелей, вроде бы, верно. Но лучше настройки туннелей делать через ЦУС.

[Отдел ИБ 0]

1. У Вас в синтаксисе ошибка. Уберите первое правило.

2. По настройкам туннелей, вроде бы, верно. Но лучше настройки туннелей делать через ЦУС.

Сделал, как Вы сказали. Все равно пишет, что ошибка в синтаксисе, причем ошибка именно в названии блока [tunnel]. С версией прошивки координатора не может быть связано (версия 1.0)?

[slavanchuk 0]

Если верить документации по HW, то без этой секции firewall.conf существовать не может. И если её нет (опять же, судя по документации),то она должна создаваться автоматически. В старых версиях HW (как сказано в документации) эти правила задавались в секции local. Так что, скорее всего, дело в прошивке.