Jump to content

Recommended Posts

Доброе время суток.

Уже 2ю неделю пытаюсь разными путями разобраться со следующей проблемой.

Есть следующая (упрощенная) схема сети. Мне дали белый внешний ip и NATируют его на мой внутренний - 10.10.45.10 (cisco). На циске я публикую 2 порта - 80 (http) и UDP 55777 для VipNet. Публикация 80го порта прекрасно работает без каких-либо сбоев. Публикация 55777 не хочет работать ни в какую. Клиенты извне не видят координатор. Внутренние, конечно же, без проблем к нему цепляются.vipnet_scheme.jpg

Немного технических подробностей:

VipNet Coordinator 3.1 (2.6318), WindowsXP Prof SP3 (виртуалка, если это имеет значение).

В журнале регистрации IP-пакетов есть странная (с моей т.зрения) строчка:

Источник: 192.168.55.45 (шлюз) Назначение: 192.168.55.14 (VipNet) Протокол: ICMP Тип/код ICMP: 5-Redirect / 0-Redirect Datagram for the Network

Событие отклонения: 34 - неподдерживаемый тип ICMP-сообщения.

Антиспуфинг выключен (пробовал и включать), режим 4й (пока настраиваю). Подключение: со статической трансляцией адресов и зафиксировано внешний IP адрес - 213.234.ххх.yyy, обнаружение атак в обе стороны выключено.

в ЦУСе в прописано следующее: E:192.168.55.14-213.234.***.yyy:55777 и 192.168.55.14

Теперь про cisco:

публикую так:

ip nat inside source list NAT interface FastEthernet0 overload # выход в интернет для машин

ip nat inside source static udp 192.168.55.14 55777 interface FastEthernet0 55777 # VipNet

ip nat inside source static tcp 192.168.55.3 80 interface FastEthernet0 80 # WEB

Extended IP access list NAT

10 permit ip host 192.168.55.3 any (2 matches)

20 permit ip host 192.168.55.14 any (41 matches)

30 deny ip any any (8093 matches)

Extended IP access list ХХХХ (для внешнего интерфейса, 10.10.45.10, было permit ip any any - результат тот же)

10 permit icmp any any (132 matches)

40 permit tcp any any eq www log (309 matches)

45 permit udp any any eq 55777 log (15604 matches)

60 deny ip any any (6144 matches)

Extended IP access list YYYY ( для внутреннего интерфейса, 192.168.55.45, так же было permit ip any any )

5 permit icmp any any (7134 matches)

10 permit ip host 192.168.55.3 any (222 matches)

20 permit ip host 192.168.55.14 any (130466 matches)

60 deny ip any any (168382 matches)

Ну вот как-то так.

В планах попробовать OS на координаторе переставить на Win2003 (от безысходности уже), либо, вынести координатор вообще в DMZ, и всех внутренних клиентов пускать через динамическое подключение через интернет (но это решение мне нравится меньше всего, хотя внутренних клиентов не очень много).

Заранее спасибо.

Share this post


Link to post
Share on other sites

Первое, что я бы сделал это до 3.2 обновил координатор. Она более стабильней работает. Какой режим работы выбран на удаленном клиенте. В предоставленном событии из журнала источником icmp является удаленный клиент или открытый пакет? С клиента пинги идут по адресу видимости? Все настройки в ЦУС корректные. Обнаружение атак тут не при чем.

Share this post


Link to post
Share on other sites

Первое, что я бы сделал это до 3.2 обновил координатор. Она более стабильней работает. Какой режим работы выбран на удаленном клиенте. В предоставленном событии из журнала источником icmp является удаленный клиент или открытый пакет? С клиента пинги идут по адресу видимости? Все настройки в ЦУС корректные. Обнаружение атак тут не при чем.

обновиться - не думал как-то, спасибо.

на удаленном клиенте - подключение через межсетевой экран, с динамической трансляцией адресов, галочка про трафик через координатор - стоит.

в событиях источником icmp является внутренний интерфейс ШЛЮЗА, т.е. открытый пакет, если точней то:

тип события: блокирован

направление: входящий

шифрование: открытый

широковещание: нешироковещательный

ethernet-протокол: 800h

удаленный клиент пингует без проблем внешний адрес шлюза

обнаружение атак уже от безысходности убирал :)

Share this post


Link to post
Share on other sites

Давай так, на клиенте открой ViPNet Client Монитор, в защищенной сети посмотри ip-адрес доступа к координатору. Если ip не отображаются, то поставь в настройках, чтобы отображались. Скорей всего адрес доступа будет виртуальным. Пусти на него пинг. На координаторе в журнале ip-пакетов должны увидеть входящий зашифрованный трафик от этого клиента с событием 40. Это есть? Если нет, то трафик до координатора не доходит...

...удаленный клиент пингует без проблем внешний адрес шлюза...

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

P.S. На клиенте в настройках координатора проверь адреса доступа к нему. Вкладка межсетевой экран.

Share this post


Link to post
Share on other sites

К сожалению никакие действия желамого результата не принесли, а время поджимало... поэтому убрал cisco и заменил ее на VipNet Coordinator, тем самым решив вышеуказанную проблему... Спасибо за помощь.

Share this post


Link to post
Share on other sites

В схемах с двойным NAT ViPNet работает, были примеры.

Правда, в этом случае для узлов ViPNet за такими NAT использовали настройки работы МСЭ с динамической трансляцией.

Подробнее можно посмотреть в https://files.infotecs.ru/_dl/sess/vipnet_demokeys/principy_marshrutizatsii_vipnet_2012.zip

Естественно, тут возникают, как минимум, 3 особенности:

1. Чтобы не запутаться, в NAT специально не настраивать пробросы 55777, а использовать общие настройки.

2. Должен быть еще один Координатор, ктоторый имеет либо собственный публичный адрес на внешнем интерфейсе (прямое подключение к Интернету), либо на NAT настроены правила статической трансляции для UDP 55777.

Тогда все остальные внешние узлы можно выставлять в режим с динамическим NAT.

3. ViPNet пытается сам определеить способы доступа к узлам, исходя их заданной в ЦУС или руками локально настроек. Поэтому лучше использовать последние версии, все-таки логика сложная, ее приходится периодически подтачивать.

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

Если нет - тоже не стесняйтесь, по крайней мере направят к аккаунт-менеджерам.

Share this post


Link to post
Share on other sites

по поводу пункта 3 прошу подробнее, в части задания политик настроек на клиентах для доступа к узлу - координатор сети. какую строку прописывать - не подскажете?

достаточно опубликовать порт 55777/udp (как лучше это сделать?) на нужном координаторе, либо еще необходимо настроить трансляцию для этого порта?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.