Jump to content
Guest demone

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

Recommended Posts

Guest demone

Добрый день!

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

Схема сети:

image.png

Результат:

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest demone

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

Спасибо.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest demone

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Guest demone

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

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

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.