Отключение Nat На Отдельном Сетевом Интерфейсе

[Олег РПА]

Здравствуйте!

Есть сеть вот с такой схемой:

Интернет подключен к координатору A и координатору D.

Координаторы B и координаторы C должны ходить в интернет через координатор A.

Все координаторы выполняют функции маршрутизаторов.

Все подсети 10.77.*.* являются внутренними, трафик между ними должен шифроваться координаторами.

Трафик, который идет в интернет, шифровать не обязательно.

Координаторы B и C соединены между собой и с координатором A через сеть IP-VPN, организуемую провайдером. Т. е. для нас это получается небезопасная сеть, и трафик при передаче через нее должен шифроваться.

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

Сейчас получается так: компьютеры из сети координатора C не видят компьютеры в сети координатора A при включенном NAT на координаторе A. Если NAT выключить, то пропадает интернет (у всех, кто подключен через координатор А), но начинаются видеться компьютеры из сети координатора А.

Наши координаторы имеют 4 порта. Можно ли как-то разделить по портам внутреннюю и внешнюю сеть (чтобы они втыкались в разные порты)? До координаторов сети работали в прозрачном режиме, т.е. провод провайдера втыкался в наш коммутатор на каждой площадке, а там, где расположен координатор А, было два провода - локальная сеть и отдельно интернет. Хочется поставить координаторы на "бутылочное горлышко" каждой площадки (как сейчас установлены координаторы A и D) и чтобы все пользователи работали через них в прозрачном для пользователей режиме.

Сейчас не можем придумать иного способа, кроме как отключить NAT на координаторе A и поставить между ним и интернетом проксю с натом, но это точно не добавит сети надежности, а нам не упростит администрирование. Существуют ли способы реализовать шифрование межсетевого трафика и выход в интернет силами только координаторов?

[slavanchuk]

Тут, наверное, имеет смысл посмотреть как у Вас настроены правила трансляции. Если они у Вас настроены на все диапазоны адресов назначений, то он будет подменять адрес и для виртуальных адресов и тут будут нестыковки. Если Вы пропишете отдельно диапазоны внешние, тот ту проблемы быть не должно (насколько я это понимаю).

И по поводу второго вопроса - можете настроить работу и через несколько интерфейсов. Только тут нужно знать особенности сети Вашего провайдера.

[Jakuro]

Тут, наверное, имеет смысл посмотреть как у Вас настроены правила трансляции. Если они у Вас настроены на все диапазоны адресов назначений, то он будет подменять адрес и для виртуальных адресов и тут будут нестыковки. Если Вы пропишете отдельно диапазоны внешние, тот ту проблемы быть не должно (насколько я это понимаю).

И по поводу второго вопроса - можете настроить работу и через несколько интерфейсов. Только тут нужно знать особенности сети Вашего провайдера.

Проблема заключается в том, что при отправке пакетов с хоста в сети координатора В в сеть координатора А при включенном нате, координатор А подменяет адрес хоста на внешний. В правилах трансляции адресов нельзя указать диапазон адресов назначения. Т.е. нельзя указать, чтобы из сети В в интернет адрес транслировался, а в сеть А - нет. И получается, что у нас работает либо интернет, либо сеть.

[slavanchuk]

Проблема заключается в том, что при отправке пакетов с хоста в сети координатора В в сеть координатора А при включенном нате, координатор А подменяет адрес хоста на внешний. В правилах трансляции адресов нельзя указать диапазон адресов назначения. Т.е. нельзя указать, чтобы из сети В в интернет адрес транслировался, а в сеть А - нет. И получается, что у нас работает либо интернет, либо сеть.

Почему же нельзя указать, когда можно?! Вы в правиле трансляции указали from 1.1.1.1 to any, а можете указать отдельно диапазоны. Я вчера перебирал ещё раз документацию - это допустимо. Можете показать свои правила NAT? И, кстати, какая у Вас прошивка HW1000? Там от версии к версии особенности конфигурирования разные бывают.

[Jakuro]

HW1000 Q2/Q3 version: 3.0 (267)

ViPNet Coordinator version: 3.7.1-(3028)

ViPNet iplir daemon version: 3.0-670

ViPNet mftp daemon version: 3.53-60

ViPNet failover daemon version: 1.5-1

ViPNet drivers versions:

Iplir:

3.3.3

Watchdog:

1.0.5

rule= num 0 proto any from 10.77.0.2-10.77.7.255 to anyip change src=80.253.x.y:dynamic

rule= num 1 proto any from 10.77.16.2-10.77.23.255 to anyip change src=80.253.x.y:dynamic

rule= num 2 proto any from 10.77.32.2-10.77.39.255 to anyip change src=80.253.x.y:dynamic

[slavanchuk]

HW1000 Q2/Q3 version: 3.0 (267)

ViPNet Coordinator version: 3.7.1-(3028)

ViPNet iplir daemon version: 3.0-670

ViPNet mftp daemon version: 3.53-60

ViPNet failover daemon version: 1.5-1

ViPNet drivers versions:

Iplir:

3.3.3

Watchdog:

1.0.5

rule= num 0 proto any from 10.77.0.2-10.77.7.255 to anyip change src=80.253.x.y:dynamic

rule= num 1 proto any from 10.77.16.2-10.77.23.255 to anyip change src=80.253.x.y:dynamic

rule= num 2 proto any from 10.77.32.2-10.77.39.255 to anyip change src=80.253.x.y:dynamic

Так, а всё-таки вместо anyip даипазоны попробуйте прописать.

[Jakuro]

Так, а всё-таки вместо anyip даипазоны попробуйте прописать.

Пробовал, ошибка в конфиге. В мануалах также сказано, что тут может быть только anyip.

[slavanchuk]

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

[Jakuro]

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

Спасибо

[AnTonN(c)]

4ая версия спасет вас в части замены лексеммы any на конкретный адрес/подсеть. Может даже до конца года выйдет.

Не понимаю, что у вас не работает?

Давайте рассмотрим подробнее:

Исходные данные: Координаторы туннелируют свои подсети. Координатор А натит все (открытый+туннелируемый трафик) в свой белый адрес.

Ситуация номер раз.

Допустим, клиент за координатором С захочет выйти в интернет - этот трафик как транзитный проходит через С, попадает на А и натится, по маршрутизации отправляется в свои ворота - в Инет. Обратные пакеты придут нормально и рассматривать их не будем.

Ситуация номер два.

Клиент за координатором С обращается в защищенную подсеть координатора А. Трафик попадает на С, шифруется, отправляется на А, натится, по таблице маршрутизации кидается на внутренний интерфейс, ответ от клиента подсети А попадает на координатор, в рамках нат сессии все уходит обратно.

Что не так? Где затык?

Пришлите вывод in sh ro.

[intellegent]

4ая версия спасет вас в части замены лексеммы any на конкретный адрес/подсеть. Может даже до конца года выйдет.

Не 4, а 3.1 и не к концу года, а раньше .

Да сейчас есть ограничение, которое будет снято и Вы сможете в правилах NAT указывать адрес назначения.