Доступ К Координатору За Мэ С Трансляцией Адресов

[Гость demone]

Добрый день!

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

Схема сети:

Результат:

ПК-1 не имеет соединения по ViPNet с Координатором, при этом ПК-1 имеет соединение c ПК-2 и c удаленным ПК.

После исключения других вариантов возможной проблемы с помощью сниффера было установлено следующее: при получении IP(UDP) пакета от клиента ПК-1 (IP адрес источника в заголовке пакета - внешний интерфейс МЭ) Координатор отправляет ответный пакет не обратно на МЭ, а на шлюз по-умолчанию, указывая в качестве адреса назначения - адрес внешнего интерфейса МЭ. И это при том, что внешний адрес МЭ находится в одном широковещательном домене с внешним адресом Координатора (В таблице ARP на Координаторе имеется запись, указывающая, что он "знает" адрес МЭ). Для проверки корректности работы на сетевом уровне на Координаторе установлен 4 режим - в таком варинте ПК-1 успешно "пингует" внешний интерфейс Координатора. Что интересно, ПК-1 может устанавливать защищенные соединения с ПК-2, при этом сниффер показывает, что в данном случае Координатор успешно выполняет маршрутизацию пакетов, передавая их на внешний интерфейс МЭ (видимо в данном случае действуют обычные правила маршрутизации ОС). При установке на Координаторе в качестве шлюза по-умолчанию внешнего интерфейса МЭ связь налаживается, ПК-1 может "достучаться" до Координатора.

В чем может быть дело? Получается, когда получателем сообщения является Координатор (софт), решение о маршрутизации принимает прикладная задача?

[AnTonN(c)]

На ПК-1 должен стоять режим со статикой или динамикой. На координаторе пропиши обратные маршруты для адреса видимости ПК-1. Или поставь версию 3.2 на координатор.

[Гость demone]

Да, такой варинт работает. При добавлении в маршруты Координатора адреса видимости клиента за МЭ (его виртуальный адрес в ViPNet) машина становится доступа. Это также объясняет, что решение о маршрутизации принимается на прикладном уровне, иначе как объяснить, что Координатор отправляет трафик на шлюз по-умолчанию с адресом назначения узла (на сетевом уровне), находящегося в одной с ним подсети. Вариант с последней версией 3.2 я пробовал - результат тот же. Добавление маршрута для нужных узлов сети вручную, конечно, не очень "красивое" решение, но, однако, это все же решение проблемы

Спасибо.

[AnTonN(c)]

Странно, что не работает в 3.2. Решение о маршрутизации принимает сетевой уровень, а не прикладной. Драйвер IpLir работает между сетевым и канальным уровнями. Во входящем пакете после расшифровки подставляется в source ip адрес видимости АП (так необходимо для технологии) и далее отправляется на вышестоящие уровни для обработки, и, соответственно, ответ шлется на source ip (адрес видимости). Для обратного пакета, когда он попадает на сетевой уровень, выбирается маршрутизация (подставляется соответствующий mac next hop'у). Далее вмешивается драйвер IpLir и ставит destination ip = firewall ip (вкладка межсетевой экран)для АП. А, так как Ethernet широковещательная технология, фрейм примет устройство только с его mac (исключения сетевые карты в Promiscuous mode). Надеюсь все понятно объяснил...

[Гость demone]

Да, логика работы теперь понятна. Получается, что это архитектурная особенность. А что с версией 3.2, в ней данная ситуация была (должна быть) как-то решена?

[AnTonN(c)]

Коротко говоря, маршрутизация выбирается по firewallip, а не по accessip.

[Гость demone]

Проверил всё еще раз с версией 3.2, заработало, и вот с какими нюансами: маршрут по-умолчанию должен быть определен, т.е. указан в таблице маршрутизации и данный IP адрес должен присутствовать в таблице ARP. Дело в том, что проверял я версию 3.2 на тестовом стенде, где указал default gateway которого не существовало и в этом случае маршрутизация по firewall IP не выполнялась. После добавления в ARP таблицу произвольной записи, указывающей на GW IP, всё начинает работать должным образом. Интересно, если указать access IP в таблице маршрутизации, то данное условие не обязательно.

Теперь всё на своих местах. Спасибо за помощь