Смена Виртуальных Адресов

[ssl_236]

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

по техническим причинам понадобилась смена виртуальных адресов из сети 11.0.0.0/24 на 10,97,92,48/27

координатор NME-RVPN в конфиге поправид старт ип перезапустил iplir адреса распределились правильно, но они не работают!

т.е. АР не видят друг друга по этим адресам, а только попреджнему по 11.0.0.0/2, тунеллируемые адреса тоже не видят эти АР хотя АР отлично видят тунеллируемые адреса.

где можно найти информацию по этой теме?

[ingenico]

Вы меняли виртуальные адреса на Координаторе, а тестируете доступ по виртуальным адресам с АП на АП.

Где логика?

АП как видел раньше другие АП по адресам из 11.0.0.0 так и продолжает видеть.

Виртуальная адресация, это то под какими виртуальными адресами видит каждый СУ другие, связанные с ним СУ или туннелируемые ресурсы.

Меняйте виртуальные адреса на самом АП.

[Rinya]

То что касаемо iplir.conf относится непосредственно к координатору, т.е. вы поменял адресацию для координатора (адреса видимости АП с координатора). Клиенты по прежнему используют адресацию 11.0.0.0 (присваивают списку защищенной сети адреса 11.0.0....). Ту же процедуру что вы выполнили с iplir.conf необходимо провернуть с клиентской частью (на каждой сменить старт IP), делается это в НАСТРОЙКИ-ЗАЩИЩЕННАЯ СЕТЬ-ДОПОЛНИТЕЛЬНЫЕ ПАРАМЕТРЫ.

Что касаемо туннелируемых ресурсов, скорее всего вы используете схему полутуннеля. и может у вас настроен нат.

[ssl_236]

То что касаемо iplir.conf относится непосредственно к координатору, т.е. вы поменял адресацию для координатора (адреса видимости АП с координатора). Клиенты по прежнему используют адресацию 11.0.0.0 (присваивают списку защищенной сети адреса 11.0.0....). Ту же процедуру что вы выполнили с iplir.conf необходимо провернуть с клиентской частью (на каждой сменить старт IP), делается это в НАСТРОЙКИ-ЗАЩИЩЕННАЯ СЕТЬ-ДОПОЛНИТЕЛЬНЫЕ ПАРАМЕТРЫ.

Что касаемо туннелируемых ресурсов, скорее всего вы используете схему полутуннеля. и может у вас настроен нат.

Спасибо, увидел, попробую.

Сейчас сначала поправил немного конфиг firewall, пакеты вроде стали проходить.

вот трейс с незащищенного тунеллируемого узла:

Удаленный IP-адрес:10.97.92.51 Исходящий интерфейс: Ethernet A Проверка связи к 1: время=121мс TTL=120 Проверка связи к 2: время=96мс TTL=120 Проверка связи к 3: время=138мс TTL=120 Проверка связи к 4: <нет ответа> Маршрут 1: время=4мс хост=10.97.88.5 Маршрут 2: время=2мс хост=10.161.195.53 Маршрут 3: <неизвестно> Маршрут 4: <неизвестно> Маршрут 5: <неизвестно> Маршрут 6: <неизвестно> Маршрут 7: <неизвестно> Маршрут 8: <неизвестно> Маршрут 9: <неизвестно> Маршрут 10: время=118мс хост=10.97.92.51 (маршрут завершен)

10.97.92.51 - это уже мой нутбук с випнетом

но это все равно пока не помогает, т.к. поверх випнета должна работать видеоконференция на h.323.

[ssl_236]

Вы меняли виртуальные адреса на Координаторе, а тестируете доступ по виртуальным адресам с АП на АП.

Где логика?

АП как видел раньше другие АП по адресам из 11.0.0.0 так и продолжает видеть.

Виртуальная адресация, это то под какими виртуальными адресами видит каждый СУ другие, связанные с ним СУ или туннелируемые ресурсы.

Меняйте виртуальные адреса на самом АП.

Наверное направильно сформулировал, топология сети такая:

Codian MCU 4215 - 10.97.88.150 > router cisco 10.97.88.1 > router cisco (gatekeeper H.323) 10.97.88.5/10.161.195.48 > router cisco 10.161.195.53/192.168.10.254 > NME-RVPN 192.168.10.254/publil inet > AP 10.97.92.51

На АР стоит софт Polycom PVX

Задача: обеспечить прохождение видеовызовов от Codian MCU 4215 & gatekeeper H.323 до АР и наоборот

[Rinya]

Была подобная ситуация, только юзали Мототелеком. У вас получается схема полутуннеля. Попробуйте прописать нат, мне это тогда помогло и я смог с клиентов подключаться к серваку мототелекома. может и вам поможет.

[Rinya]

И еще попробуйте статическую трансляцию.

[ssl_236]

Была подобная ситуация, только юзали Мототелеком. У вас получается схема полутуннеля. Попробуйте прописать нат, мне это тогда помогло и я смог с клиентов подключаться к серваку мототелекома. может и вам поможет.

Можете уточнить нат в какую сторону делали во внутреннюю сеть или во внешнюю т.е. к АР. Нат какой в firewall.conf? или просто на циске?

[ssl_236]

И еще попробуйте статическую трансляцию.

Статическю трансляцию такого вида предлагаете: если на координатор из внутренней сети прилетает пакет для 10,97,92,51 то он его транслирует в виртуальный адрес АР типа 11,0,0,х ??? соответственно и наоборот.

[ssl_236]

И еще попробуйте статическую трансляцию.

Почитал доку по трансляции адресов, немного не понял там пример для выхода в интернет описан, а мне этого не надо

У меня такая конструкция получается

[nat]

rule = num 1 change src=11.0.0.1:dynamic proto tcp from any to 10.97.92.51

т.е. пакеты которые прилетают из внутренней сети на координотор для 10.97.92.51 меняються в заголовке source ip на адрес координатора 11.0.0.1 и отсылаются без изменения портов на 10.97.92.51

а вот нужно ли писать в этом случае обратное правило трансляции я что то не пойму

[Rinya]

У вас отрабатывает это правило?

Вы можете с клиента дозвониться до сервера кодиан?

[ssl_236]

Может подскажете другое решение. Корень проблемы что в сети имеется два координвтора, через которые ходят разные организации к одним и темже внутренним ресурсам, второй (не наш) координатор смотрит в вышестоящий координватор (который очень далеко стоит). на роутере за которым находятся необходимые ресурсы стоит маршрутизация:

ip route 11.0.0.0 255.255.255.0 10.x.x.x, соответственно на нашу сеть такой маршрут уже не пропишешь. Поэтому и решили вырезать диапазон из внутренней сети и отдать его на АР vipnet

[Rinya]

Объясню как было у меня, может поможет.

У нас был сервер мототелекома. Схема подключения полутуннель.

Получается мы прописали координатору в туннели IP сервера мототелекома. Затем мы прописали правило динамического ната.

Т.е. пакеты приходящие с ip клиентов (виртуальные адреса) транслировать в ip координатора со стороны которого находится ресурс.

Вот так у нас отрабатывало. Мы могли с клиента зайти на веб интерфейс сервера мототелеком и войти в конференцию. могли запустить клиента и дозвониться с него на сервер.

[ssl_236]

У вас отрабатывает это правило?

Вы можете с клиента дозвониться до сервера кодиан?

нет правило это еще не прописывали т.к. придется вернутья к стандартным виртуальным ip адресам т.е. пока спросил ваше мнение по этой конструкции

[ssl_236]

Объясню как было у меня, может поможет.

У нас был сервер мототелекома. Схема подключения полутуннель.

Получается мы прописали координатору в туннели IP сервера мототелекома. Затем мы прописали правило динамического ната.

Т.е. пакеты приходящие с ip клиентов (виртуальные адреса) транслировать в ip координатора со стороны которого находится ресурс.

Вот так у нас отрабатывало. Мы могли с клиента зайти на веб интерфейс сервера мототелеком и войти в конференцию. могли запустить клиента и дозвониться с него на сервер.

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

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

[Rinya]

Давайте обрисуем подробнее схему, может что и предложу.

как у вас организованно

РЕСУРС - КООРДИНАТОР (ЧЕЙ) - КООРДИНАТОР (ЧЕЙ) - КЛИЕНТЫ С ПО VIPNET CLIENT

[ssl_236]

Давайте обрисуем подробнее схему, может что и предложу.

как у вас организованно

РЕСУРС - КООРДИНАТОР (ЧЕЙ) - КООРДИНАТОР (ЧЕЙ) - КЛИЕНТЫ С ПО VIPNET CLIENT

Ресурс внутри сети: Codian MCU 4215 - 10.97.88.150 <=> router cisco 10.97.88.1 <=> router cisco (gatekeeper H.323) 10.97.88.5/10.161.195.48 <=> router cisco (с модулем NME-RVPN) 10.161.195.53/192.168.10.254 <=> NME-RVPN 192.168.10.253/public inet <=> AP 10.97.92.51 (клиент с ПО VIPNET CLIENT 3.1 (4.8344))

[ssl_236]

Давайте обрисуем подробнее схему, может что и предложу.

как у вас организованно

РЕСУРС - КООРДИНАТОР (ЧЕЙ) - КООРДИНАТОР (ЧЕЙ) - КЛИЕНТЫ С ПО VIPNET CLIENT

еще забыл добавить интерфейсы координатора NME-RVPN стоят в 3 режиме

[Rinya]

Тогда еще пару вопросов.

192.168.10.253 ваш координатор?

Кто туннелирует кодиант?

Можете ли вы со своего координатора пинговать кодиант?

нет ли возможности обновить клиента до версии 3.2?

[ssl_236]

Пробую конструкцию нат как по мануалу сделать

rule= num 1 change src=192.168.10.253:dynamic proto tcp from 10.97.92.48/28 to any

т.е. все что приходит от 10.97.92.48/28 к любому dest отправлять с 192.168.10.253:dynamic вроде правильно все но ругается при попытке записать

line 13: unexpected end of input

Error during parsing firewall rules

Error while loading config

[ssl_236]

Тогда еще пару вопросов.

192.168.10.253 ваш координатор?

Кто туннелирует кодиант?

Можете ли вы со своего координатора пинговать кодиант?

нет ли возможности обновить клиента до версии 3.2?

192.168.10.253 внутренний интерфейс нашего координатора

кодиант тунеллирует координатор

vipnet# inet ping 10.97.88.150

Pinging 10.97.88.150, press Ctrl+C to stop

PING 10.97.88.150 (10.97.88.150): 56 data bytes

84 bytes from 10.97.88.150: icmp_seq=0 ttl=252 time=3.7 ms

84 bytes from 10.97.88.150: icmp_seq=1 ttl=252 time=3.6 ms

84 bytes from 10.97.88.150: icmp_seq=2 ttl=252 time=3.5 ms

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

[ssl_236]

Тогда еще пару вопросов.

192.168.10.253 ваш координатор?

Кто туннелирует кодиант?

Можете ли вы со своего координатора пинговать кодиант?

нет ли возможности обновить клиента до версии 3.2?

вот кусок конфига

id= 0x098f000d

name= CM_NME-RVPN

filterdefault= pass

ip= 192.168.10.253

ip= *,*,*,

скип

tunnel= 10.97.88.150-10.97.88.150 to 10.97.88.150-10.97.88.150

скип

firewallip= 192.168.10.253

[Rinya]

Пробую конструкцию нат как по мануалу сделать

rule= num 1 change src=192.168.10.253:dynamic proto tcp from 10.97.92.48/28 to any

т.е. все что приходит от 10.97.92.48/28 к любому dest отправлять с 192.168.10.253:dynamic вроде правильно все но ругается при попытке записать

line 13: unexpected end of input

Error during parsing firewall rules

Error while loading config

кажется забыли в конце дописать anyip, не просто any

[Rinya]

скачать можете прям с сайта инфотекса.

[ssl_236]

кажется забыли в конце дописать anyip, не просто any

не проходит

GNU nano 1.3.7 File: /tmp/vipnet/user/firewall.conf

[settings]

[antispoof]

antispoof=no

eth0=internal,192.168.10.253/30

eth1=external,anypublic

[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 change src=192.168.10.253:dynamic proto tcp from

10.97.92.48/28 to anyip

[local]

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

[ Wrote 22 lines ]

line 13: unexpected end of input

Error during parsing firewall rules

Error while loading config

<I_CFG> Command: iplir config Uncorrect config file

To rollback changes and to return to a former copy

of a file of a configuration? [Yes/No]