Clent 4.3.2

[rfvbk]

версия 3.2 отличается в настройках от 4.3 таким моментом как показано на рисунке. Существует ли возможность в версии 4.3.2 выбрать в настройках какими-нибудь способом "Использовать межсетевой экран Координатор". Может где-то подправить в файлике? Или существует версия vipnet clienta 4.* где можно выбрать.

Проблема в следующем:

1) Ставлю клиента 4.3

2) инициализирую dst файлом

3) запускаю монитор, не доступен координатор, все оставшиеся клиенты видны, даже те которые находятся за другим портом эзернет

4) деинсталирую 4.3, оставляя файлы инициализации

5) ставлю версию 3.2

6) запускаю монитор 3.2,  координатор не доступен

7) смотрю в настройках стоит галка использовать монитор с динамической трансляцией адресов,

 - убираю галку с использовать межсетевой экран, и координатор доступен

 - ставлю галку Использовать межсетевой экран  и выбираю значение Координатор, и координатор тоже доступен

- если выбирать со статической или динамической трасляцией, то координатор НЕдоступен

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

9) обновляю версию клиента до 4.3.2

10) запускаю монитор, координатор доступен

я так понимаю что там по умолчанию после обновления версии остается настройка из версии 3.2

а как бы без этих манипуляций добиться в версии 4.3.2 установки этих настроек.

 

если клиент 4.3 находится в одной подсети, то он видит координатор всегда без манипуляций

[KIV]

4.3.х сам определяет тип МЭ.

[rfvbk]

48 минуты назад, KIV сказал:

4.3.х сам определяет тип МЭ.

так у меня определяет как с динамич трансляцией и из-за этого координатор недоступен

[Vintik]

Странно, обычно версия 4 вроде "умнее" ищет и находит себе путь.

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

[KIV]

Мне 4.3.2 не нравиться, 4.3.1 и стабильнее и зависимостей от обновлений на Винду нет. Попробуйте 4.3.1.

[Vintik]

Есть такое, где то кто то и на 3.1 до сих пор без проблем работает, но требуют.. а там вы же видели новости, ФСТЭК вовсе все версии до последней которая на сайте и пока не имеет сертификата ФСТЭК, с устранением очередной уязвимости.

[rfvbk]

10 час назад, Vintik сказал:

Странно, обычно версия 4 вроде "умнее" ищет и находит себе путь.

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

выставлял реальные ip. В журнале на клиенте пакеты уходят. Но ответов от координатора нет. На координаторе среди заблокированных нет. Есть предположение что координатор ответы отправляет на другой порт(инетовский). Хотя route прописан на координаторе. Если перенести комп в туже подсеть куда смотрит порт координатора или подключить через инет, то всё норм. Т.е. один из портов координатора 10.6.1.6 с маской 255.255.248, делаем ip клиента 10.6.1.20 и координатор доступен.подключаем комп в другую подсеть 10.64.64.71 и координатор недоступен по f5. Но всех других пользователей он видит, только, даже тех кто сидит на других портах координатора.

А где можно скачать версию 4.3.1 на попробовать

[denis.r]

Клиент версии 4.3 всегда использует режим с динамической трансляцией- он наиболее универсален. В данном случае, скорее всего, проблемы с маршрутизацией на координаторе. Можете накидать схему сети с адресами и вывод route print и inet show interface с координатора?

[rfvbk]

[rfvbk]

23 часа назад, denis.r сказал:

Клиент версии 4.3 всегда использует режим с динамической трансляцией- он наиболее универсален. В данном случае, скорее всего, проблемы с маршрутизацией на координаторе. Можете накидать схему сети с адресами и вывод route print и inet show interface с координатора?

на картинках заменил внешний белый ip на A.B.194.2 и шлюз аналогично на A.B.194.1

А может ли быть эта проблема связана с тем что на координаторе версия 3.6, т.е. его еще не обновил до 4 версии?

[KIV]

Это для всех клиентов с картинки такая проблема? И реально ли обновить координатор до версии 3.5(1330) хотя бы?

[rfvbk]

19 час назад, KIV сказал:

Это для всех клиентов с картинки такая проблема? И реально ли обновить координатор до версии 3.5(1330) хотя бы?

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

Если я правильно понимаю, то настройка использовать межсетевой экран с динамической трансляцией адресов, означает что между клиентом и координатором стоит динамический нат. А у меня между клиентом и координатором нет nat'а.

Если удалить с компа клиента и на порту координатора с ip 10.6.1.6 выставить режим 4, то с компа координатор пингуется.

Есть идея сменить шлюз по умолчанию на координаторе на 10.6.0.10. И посмотреть, хотя мало вериться что это поможет проверке.

На координаторе стоит 3.6, я могу обновить до 4.2(точно не помню какую версию прислали). Или стоит попробовать до 3.5

 

[KIV]

3.6 это версия iplir, а версия ПО у вас тогда 2.х на нее все равно сертификат истек, да и старая она.

[denis.r]

В 16.09.2017в21:11, rfvbk сказал:

На координаторе стоит 3.6, я могу обновить до 4.2(точно не помню какую версию прислали). Или стоит попробовать до 3.5

С маршрутизацией, вроде проблем нет. Попробуйте обновить ПАК до версии 4.2.

[rfvbk]

6 часов назад, denis.r сказал:

С маршрутизацией, вроде проблем нет. Попробуйте обновить ПАК до версии 4.2.

обновил до 4.2 резервный ПАК. Но роуты прописал не все. Для проверки сделал вот,что

1) стоит шлюз по умолчанию А.В.194.1 (inet route add default next-hop A.B.194.1)

2) добавил статический маршрут inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0

для клиента с ip 10.64.64.71 координатор не доступен

удалил шлюз по умолчанию A.B.194.1 и прописал шлюзом по умолчанию 10.6.0.10.(inet route add default next-hop 10.6.0.10) и координатор стал ДОСТУПЕН.

Почему так? не понял... Получается что пакет предназначенный для 10.64.64.71 уходил на порт с белым ip(использовал маршрут по умолчанию), вместо того чтобы уходить через порт 10.6.1.6 на шлюз 10.6.0.10. Странно. Или я что-то не понимаю..

[basid]

if (subnet & mask != gate & mask) assert("Epic fail")

[rfvbk]

4 часа назад, basid сказал:

if (subnet & mask != gate & mask) assert("Epic fail")

Так у меня вроде норм?

subnet & mask = 10.6.0.0

gate & mask = 10.6.0.10 & 255.255.248.0 = 10.6.0.0

10.6.0.0 == 10.6.0.0

 

[basid]

> 2) добавил статический маршрут inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0

10.64.64.0/24 == 10.64.64.0

10.6.0.10/24 == 10.6.0.0

[Vintik]

Какой итог то? Мы победили или ещё боремся? Я уже запутался.

[rfvbk]

14 часов назад, basid сказал:

> 2) добавил статический маршрут inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0

10.64.64.0/24 == 10.64.64.0

10.6.0.10/24 == 10.6.0.0

1) у координатора ip 10.6.1.6 он находится в подсети 10.6.0.0/21. в этой подсети шлюз 10.6.0.10

2) за шлюзом 10.6.0.10 находится подсеть 10.64.64.0/24

3) для того чтобы пакет предназначенный для ip 10.64.64.71 из координатора(10.6.1.6) попал на шлюз 10.6.0.10 и дальше попал в подсеть 10.64.64.0/24

прописал статический маршрут inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0

Разве не так делается?

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

Какой итог то? Мы победили или ещё боремся? Я уже запутался.

неее, я не пойму почему статический маршрут не применяется, а применяется шлюз по умолчанию

[Vintik]

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

[rfvbk]

3 часа назад, Vintik сказал:

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

спасибо за идею, но не помогло, но частично вывело на выводы.

Удалил шлюз по умолчанию, оставил только маршрут на подсеть 10.64.64.0/24 ( inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0 ). Координатор не доступен.

Добавил шлюз по умолчанию 10.6.0.10. Координатор стал доступен.

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

Так должно быть?

[basid]

4 часа назад, rfvbk сказал:

1) у координатора ip 10.6.1.6 он находится в подсети 10.6.0.0/21. в этой подсети шлюз 10.6.0.10
2) за шлюзом 10.6.0.10 находится подсеть 10.64.64.0/24
3) для того чтобы пакет предназначенный для ip 10.64.64.71 из координатора(10.6.1.6) попал на шлюз 10.6.0.10 и дальше попал в подсеть 10.64.64.0/24 прописал статический маршрут inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0

Разве не так делается?

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

Следовательно, "route -p add 10.0.0.0 mask 255.0.0.0 10.6.0.10" на клиенте должно решить вашу проблему.
Чтобы вообще не думать обо всей этой ерунде - маршрутиризацию надо настраивать в одном месте. А это - "шлюз по умолчанию".

P.S. Вот только не надо рассказывать каким образом "в продвинутых системах" можно строить извращённые схемы - изврат не должен быть ни самоцелью, ни стандартной практикой.

[rfvbk]

43 минуты назад, basid сказал:

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

Следовательно, "route -p add 10.0.0.0 mask 255.0.0.0 10.6.0.10" на клиенте должно решить вашу проблему.
Чтобы вообще не думать обо всей этой ерунде - маршрутиризацию надо настраивать в одном месте. А это - "шлюз по умолчанию".

P.S. Вот только не надо рассказывать каким образом "в продвинутых системах" можно строить извращённые схемы - изврат не должен быть ни самоцелью, ни стандартной практикой.

Есть предположение, что вы меня не поняли

У координатора 3 нужных порта: 

1)порт внешний ip = A.B.194.2 

2)порт выходящий на "локалку №1" : ip = 10.6.1.6 (сеть 10.6.0.0/21)

3)порт выходящий на "локалку №2" : ip = 192.168.6.254 (сеть 192.168.6.0/24)

в локалке №1 есть шлюз 10.6.0.10, за которым есть подсетка 10.64.64.0/24

в подсетке 10.64.64.0/24 шлюз 10.64.64.1.

на компе 10.64.64.71 стоит шлюз по умолчанию 10.64.64.1

(между 10.6.1.6  и 10.64.64.71 есть шлюз. 10.6.1.6 и 10.64.64.71 находятся в разных подсетях)

10.6.1.6 находится в подсети 10.6.0.0/21

10.64.64.71 находится в подсети 10.64.64.0/24

на координаторе прописан маршрут  inet route add 10.64.64.0 next-hop 10.6.0.10 netmask 255.255.255.0. Этот маршрут говорит о том что клиент с 10.64.64.71 находится за портом выходящим в подсеть 10.6.0.0/21 за шлюзом 10.6.0.10.

1) Комп 10.64.64.71 без vipnet-клиента нормально пингует 10.6.1.6

2) комп 10.64.64.71 с vipnet клиентом 3.2 c убранной галочкой использовать межсетевой экран нормально видит координатор и пингует 10.6.1.6

3) комп 10.64.64.71 с vipnet клиентом 3.2 c поставленной галочкой использовать межсетевой экран с динамической трасляцией адресов не видит координатор и не пингуется 10.6.1.6

4) комп 10.64.64.71 с vipnet клиентом 4.3 не видит координатор и не пингуется 10.6.1.6 (у него автоматически стоит  использовать межсетевой экран с динамической трасляцией адресов, т.е. как в случае 3)

 

[basid]

Добавлю ещё один хинт - везде (и на клиентах и на координаторах) в фильтрах и открытой и защищённой сети первым ставьте правило, запрещающее ICMP Redirect (код 5).