Виртуальный адрес

[Chezok]

Добрый день!

Задался тут одним вопросом при "тестировании" координатора HW с версией прошивки 4.2.1, а именно:

В координаторах HW в прошивках младше 4 версии была возможность менять виртуальный IP адрес видимости других узлов. К примеру какого нить ViPnet Client, достаточно было в параметре к примеру:

virtualip= 11.0.0.14 поменять IP например на 12.0.0.14

 

После чего обратно запустить iplir и данный клиент уже будет виден по новому IP 12.0.0.14 вместо 11.0.0.14.

 

В версии 4 (а именно 4.2.1) такой способ уже не помогает, после запуска iplir у клиента возвращается его изначальный виртуальный IP 11.0.0.14.

 

Есть ли возможность в 4 версии задать вручную определенный виртуальный IP адрес клиенту со стороны координатора HW, или уже нет ?

[denis.r]

Подробно в документации http://docs.infotecs.ru/#123/50322.htm

[Vintik]

В теории должно быть можно, надо мануалы посмотреть, может больше к ЦУС привязали или приоритет выше при опросе, вы поменяли, а он опрашивает, видит что тот был с таким IP и снова делает такой же. Я так понял вы IP ставили любой, даже который не принадлежал "общему" диапазону. 

[Chezok]

10 минуту назад, Vintik сказал:

В теории должно быть можно, надо мануалы посмотреть, может больше к ЦУС привязали или приоритет выше при опросе, вы поменяли, а он опрашивает, видит что тот был с таким IP и снова делает такой же. Я так понял вы IP ставили любой, даже который не принадлежал "общему" диапазону. 

Совершенно верно, в 3.2 если установленный IP не пересекался с кем либо (и даже если не попадал в "общий" диапазон), то он присваивал его. Теперь скидывает на тот, который считает правильным. Попробовал сменить на IP, который входит в диапазон и не повторяется, всё равно после запуска скидывает на изначальный.

 

P/s: В документации нет ни слова о ручной смене виртуального адреса, только лишь правила назначения из выделенного диапазона заданного в отдельной настройке, и задании видимости по реальному и виртуальному, мой вопрос не раскрывается. Поэтому и задал вопрос тут.

P/s: В приведённой сылке выше идёт описание смены туннелей, а речь про другие СУ (не туннели) к примеру ViPNet Client. Сменить виртуальный IP на другой произвольный.

[Chezok]

Как я понял из документации. Теперь нельзя задать определённый виртуальный адрес. Выдаются автоматически только из того диапазона, который задан. При этом его в принципе сменить нельзя даже на тот, который попадает в диапазон... что довольно странно.

Вообще эта возможность была критически важной, не думал что она за тронется в версии 4.2. Теперь стоит вопрос, есть ли возможность удалённо сделать даунгрейд прошивки с версии 4.2 до 3.5 для координаторов HW ?

[denis.r]

В 12.08.2017в09:45, Chezok сказал:

В координаторах HW в прошивках младше 4 версии была возможность менять виртуальный IP адрес видимости других узлов.

Разве в версии 3.х такое работало?

[Chezok]

4 минуты назад, denis.r сказал:

Разве в версии 3.х такое работало?

Да, у нас на 2 "пограничных" координаторах с версией 3.5 некоторым ViPnet Client сменены вручную виртуальные адреса на определённые, для доступа в сети, в которых есть ограничения по заданным IP адресам. Соответственно с 4.2 пропадает возможность попадать в эти сети. Всем выдать так же нет возможности, ограничена сеть по маске 24 а узлов более 2000.

 

Остаются мысли лишь вернутся на 3.5

[denis.r]

3 минуты назад, Chezok сказал:

сменены вручную виртуальные адреса на определённые

А адреса попадают в диапазон виртуальных адресов? 

 

В 12.08.2017в09:45, Chezok сказал:

virtualip= 11.0.0.14 поменять IP например на 12.0.0.14

В примере вы привели адреса совершенно из разных диапазонов, такое вряд ли можно было сделать в версии 3.х.

6 минут назад, Chezok сказал:

Остаются мысли лишь вернутся на 3.5

Процедуры понижения версии нет. Только полная перепрошивка.

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

[Vintik]

А зачем вам менять виртуальный адрес? Там же в целом диапазон такой, что столько хостов то не был в жизни :-)

И чем не устраивает "реальный", если уж надо конкретно и стабильность? По моему назначить "использовать только реальный этот" осталась и не кто не отменял.

[Chezok]

А адреса попадают в диапазон виртуальных адресов? - Нет

В примере вы привели адреса совершенно из разных диапазонов, такое вряд ли можно было сделать в версии 3.х. - Работает, сейчас попробовал

вывод команды ver на координаторе.

Platform: HW2000 Q2/Q3
Version: 3.5 (741)

ViPNet Coordinator version: 3.7.3-(6950)

Одному из ViPnet Client в секции [id] изначальный параметр virtualip равен 11.0.0.9, сменил его на 15.0.0.9, после чего запустил iplir, данный клиент стал доступен по 15.0.0.9. Сменил обратно на 11.0.0.9 и запустил снова iplir. Клиент снова стал доступен по 11.0.0.9

 

Проблема в том, что у координатора есть взаимодействие с внутренней сетью гос организации. С которой нам сообщили, что будут пускать подключения только из сети (к примеру) 10.10.10.0/24. При этом необходима двухсторонняя связь (что бы могли подключаться как из этой сети, так и в эту сеть), поэтому определённым клиентам задали вручную определённые виртуальные адреса. И всё это работало. Соответственно гос организация не хочет идти на встречу и что нить дополнительно добавлять или менять со своей стороны.

P/s: Сейчас ответила тех. поддержка по почте, сообщили что данный сценарий не "рабочий" и в версии 4.Х, и что не был рабочим в 3.Х. Поэтому к вечеру будем перепрошивать обратно на 3.5

[Vintik]

15 минуту назад, Chezok сказал:

.....

Остаются мысли лишь вернутся на 3.5

Мне кажется это плохая мысль, т.к. вы понимаете "не сегодня так завтра" останется только версия 4 (я не про работоспособность конечно как вы понимаете, версия 3 и через 1000 лет будет работать (если конечно кто то потом будет обладать такими технологиями, я тут по просьбе Вин-95 кое как на вирт поднял, там есть ПО которое не идёт на новых ОС, хотя вроде вот недавно всё знал по нему и было.. а уж если принесеут дискету 5.25 то думаю вовсе не помогу, т.к. всё уже викинул, на 3,5 ещё пока есть флопики... ).

Ну и если вернуться к теме, лучше сейчас вам брать на земетку, что было и было полезно и Инфотексу это отписывать. чтоб вернули или искать другое решение. Думаю любой умный производитель прислушивается к тому что хотят его пользователи и по возможности старается исполнять (на пример по НСД я как то проверял.. потом отписывал что и ка было бы очень удобно, а что то и вовсе необходимо т.к. не работает и в бэта версиях видел эти решения, тут понимаю с Инфотексом гораздо сложнее это решать, т.к. они только от "крупных" клиентов что то слушают, а мы так.. но всё же с миру по нитки, а там может и другие компании на рынке появятся.)

Я одну тему поднял в разделе "обращения" и понимаю что пусть там пока 5 голосов, но уже больше трёх и кто знает, может в будущем что то да исправится.

[Chezok]

1 минуту назад, Vintik сказал:

Мне кажется это плохая мысль,

Я с вами согласен. Это не решение проблемы, но необходимо чтобы работало "уже сейчас". Поэтому откат неизбежен, и в дальнейшим учтём эту особенно и будем решать, как двигаться дальше.

[Vintik]

18 минуту назад, denis.r сказал:

В примере вы привели адреса совершенно из разных диапазонов, такое вряд ли можно было сделать в версии 3.х..

Я тоже про это задумывался, но до конца так и не понял, как там они работают. может вы поясните? Я понимал там в теории  нет не классификации и нет масок, потому всегда был вопрос, что для них на пример те же  11.0.0.14 и 12.0.0.14  ? На пример прописывается тунель на IP а какая маска вовсе не понятно, на пример если по класификации типа брать на 10.х,х,х она 255,0,0,0 но если 255,255,255,0 то как випнет это понимает, а ведь понимает в итоге - одни загадки.

Потому если там вирт. просто диапазон, то ему не важно 11 или 12, он может от 0,0,0,0 до 255,255,255,255 всё подряд как цифры принимает. 

[Vintik]

7 минут назад, Chezok сказал:

Я с вами согласен. Это не решение проблемы, но необходимо чтобы работало "уже сейчас". Поэтому откат неизбежен, и в дальнейшим учтём эту особенно и будем решать, как двигаться дальше.

А если "тупо" загнать как вы хотели в тунели и по моему там оставалась возможность, что реальные вот такие - отображаемый вот такие. Обычно они одни и те же, но для таких случаев как у вас как раз вроде и применятся та "путаницы" чтоб сбить с толку врага :-)

\ Выпросить для тестов и обучения HW-VA не реально,  дали на 3 месяца и всё :-( потому так и не научился толком не чему и протестировать не начем, только на Линукс координаторе как то пытался и могу что то делать, но это немного не то.. потому и пишу немного не так как профи, но одним глазом "пару минут" пришлось поработать, потому больше от вас узнаю, какие проблемы и т.п и пишу больше только предположения. \

[Chezok]

2 минуты назад, Vintik сказал:

А если "тупо" загнать как вы хотели в тунели и по моему там оставалась возможность, что реальные вот такие - отображаемый вот такие. Обычно они одни и те же, но для таких случаев как у вас как раз вроде и применятся та "путаницы" чтоб сбить с толку врага :-)

Так реализовано с теми, у кого есть координаторы. Просто виртуализированы туннели в нужные адреса.

Но есть точки, где только один ViPnet Client, с ними такое не поможет уже.

[Vintik]

18 минуту назад, Chezok сказал:

Так реализовано с теми, у кого есть координаторы. Просто виртуализированы туннели в нужные адреса.

Но есть точки, где только один ViPnet Client, с ними такое не поможет уже.

Разве у него во вкладке "Тунель" они будут другие? (нет под рукой к сожалению дэмо стенда, потому не помню как там у самого клеинта они выбираются, но вроде у каждого клиента они свои, если их не так много, то на машине клиента можно определить совой диапазон и чтоб ещё больше "запутать", снять галочку "не тунелировать свои").

Но в вашем случае (т.к. вы писали требуют уже вчера, пока вернуть всё как было, а к тому времени как уже придётся использовать только версию 4, решение уже придумаете.

[KIV]

Функционал о котором топикстартер говорит нужен, у нас без него ещё не скоро на 4.х переехать получится. Так что если сотрудники Инфотекс читают эту ветку, то +100500 за ручное назначение виртуальных адресов не из диапазона для туннелируемых ресурсов.

[denis.r]

13 часов назад, KIV сказал:

+100500 за ручное назначение виртуальных адресов не из диапазона для туннелируемых ресурсов.

Диапазоны виртуальных адресов для туннелей и для узлов сети в версии 4.х и так разделены. И для туннелей можно задавать вручную.

[Vintik]

Интересно это не то что вы хотели?

====

Что нового в версии 4.2 
В этом разделе представлен краткий обзор изменений и новых возможностей ViPNet Coordinator 
HW версии 4.2 по сравнению с версией 4.1.3. Информация об изменениях в предыдущих версиях 
содержится в приложении История версий (на стр. 70). 
...
Автоматический и ручной режимы назначения виртуальных адресов туннелируемых узлов 
В новой версии появилась возможность выбора автоматического или ручного режима 
назначения виртуальных адресов туннелируемых узлов (параметр tunnel_virt_assignment 
секции [misc] файла iplir.conf). По умолчанию в новой версии ViPNet Coordinator HW 
виртуальные адреса для туннелируемых узлов задаются в автоматическом режиме. В случае 
обновления ViPNet Coordinator HW до текущей версии происходит проверка файла 
iplir.conf на наличие настроек туннелируемых узлов, и если такие настройки есть, то 
устанавливается ручной режим назначения виртуальных адресов туннелируемых узлов и 
настройки сохраняются. 

Настройка видимости туннелируемых узлов 
В предыдущих версиях ViPNet Coordinator HW адреса видимости туннелируемых узлов 
определялись только вручную, и в результате обновления программного обеспечения на узле, 
на котором были вручную настроены виртуальные адреса туннелируемых узлов, такие узлы 
могли стать недоступны. 
Теперь вы можете настроить для ViPNet Coordinator HW видимость всех туннелируемых им 
узлов по реальным или виртуальным адресам с помощью параметра tunnelvisibility 
секции [id] файла iplir.conf. 
Подробную информацию о параметрах для настройки туннелирования см. в документе 
«ViPNet Coordinator HW. Справочное руководство по конфигурационным файлам».  

[Chezok]

В 15.09.2017 в 20:27, Vintik сказал:

Интересно это не то что вы хотели?

назначения виртуальных адресов туннелируемых узлов (параметр tunnel_virt_assignment 
секции [misc] файла iplir.conf).

Данный параметр задает видимости туннельных ресурсов. Моя речь была про защищённые узлы и их параметр virtualip

[Vintik]

Как решили то? Или только в надежде осталось ждать, что вернут как было?

[Chezok]

В 20.12.2017 в 15:20, Vintik сказал:

Как решили то? Или только в надежде осталось ждать, что вернут как было?

Будет отдельный координатор для этой площадки. На котором поменяем выдаваемый пул виртуальных адресов на нужный. Это в принципе решение заказчика.

Если не было бы нужды подключаться со стороны туннелей на клиентские машинки, можно было бы всё решить обычным NAT на координаторе.

[Sarkan]

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

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

[Chezok]

В 16.01.2018 в 12:44, Sarkan сказал:

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

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

Я вас совсем не понял.

 

По поводу второго. Клиент отказывается от покупки координатора, и покупает клиент для сервера. Туннелировать в итоге его не возможно (банально нечем).

 

По поводу NAT, необходимо двустороннее поддержание связи, как правильно подметили, идёт связка Сервер-Сервер. При том, что один из серверов отвечает только определённой сети, скажем 10.10.10.0/24. Все остальные разбросаны по области (не медицина). Как реализовать это в виде NAT ? Если на координаторе задать правило NAT, при обращении скажем к туннелю 192.168.0.1 (сервер, который отвечает только сети 10.10.10.0/24) от определённых адресов защищённой сети, координатор его отправит от своего адреса, то да, 192.168.0.1 ответит обратно. Вопрос, как сделать так, что бы 192.168.0.1 мог подключаться в обратную сторону до конкретных серверов (которые по его логике должны быть в сети 10.10.10.1/24 и доступность которых он мониторит), хотя клиентам присвоены иные адреса.

[w03zd8rc]

Как я это реализовывал.

Например: клиент 1 имеет реальный 192.168.1.1, а клиент 2 должен видеть его как 10.10.10.1, клиент 2 пусть имеет 10.10.10.10

Между клиентом 1 и координатором ставится маршрутизатор (например mikrotik (не реклама)). На самом маршрутизаторе делается нат:

1. srcnat src-address 192.168.1.1 действие src-nat 10.10.10.1, если более тонко то и в условие dst-address 10.10.10.10

2. dst-nat dst-address 10.10.10.1 действие dst-nat 192.168.1.1

Ну и маршрутизацию через этот маршрутизатор не забываем.

В итоге получаем: координатор, и клиент 2 соответственно, видят клиента 1 по адресу 10.10.10.1, при необходимости можно вписать его в секцию туннеля. А клиент 1 обращается к клиенту 2 по 10.10.10.10