Jump to content

Recommended Posts

День добрый!

Имеется следующая схема:

vipnet2.png.964c923126312f174fa3c089c114cb80.png

ПАК - координатор HW1000

Сеть 2 - клиенты с випнет клиентом, шлюз у них НЕ ПАК.

Сеть 1 - клиенты без випнет клиента, изолированы своей приватной сетью, в интернет и прочие места (кроме своей приватной сети) ходят через ПАК. Соответственно, на ПАК прописаны в туннеле, сеть 2 обращается к ним ч/з ПАК, как к туннелям.

Всё работает как надо.

Но в один прекрасный момент начинают наблюдаться странные вещи:

один клиент из сети 2 (назовём его К2) не может достучаться до одного клиента из сети 1 (К1). Причём не может достучаться только по одному порту, например если он постоянно работает по RDP, то начинает выдавать ошибку при попытке подключения по RDP, но по сети заходит, пингует, дополнительное ПО, которое работает на нём, тоже соединяется. К2 на другие клиенты из Сети 1 заходит, только с этим и только по одному порту проблема. Если у К2 сменить IP - проблема уходит, но на некоторое время. Проблема возникает в случайном порядке на разных клиентах, причём на других, во время возникновения проблемы, это никак не влияет - продолжают работать.

На ПАК включено полное логирование - в логах всё пропускает, ничего не блокирует. Правила в разделе [tunnel] фаервола позволяют эти соединения.

На клиентах в сети 1 выключен штатный windows фаервол, в системном журнале ошибок никаких нет.

Share this post


Link to post
Share on other sites

Огласите список версии випнета на координаторе, клиентах и какие антивирусы с какими компонентами стоят на проблемных компах

Share this post


Link to post
Share on other sites

Координатор:

Platform: HW1000 Q2/Q3
Version: 3.2 (728)

ViPNet Coordinator version: 3.7.3-(5761)

Клиенты 4.2 (3.27262) и 3.2 (11.21139)

Антивириус - Касперский, но его я пробовал удалять на клиентах.

Share this post


Link to post
Share on other sites

Доброго времени суток.

Может странное предположение, но все же - возможно у Вас где-то пересечение ip адресов происходит?

В сети 1 и сети 2 разная адресация?

На випнет клиентах какой тип межсетевого экрана?

И еще данная проблема наблюдается на клиентах разной версии или на какой то определенной редакции?

Share this post


Link to post
Share on other sites

Пересечения адресов нет, адресация разная в сетях. В сети 1 шлюзом выступает координатор.

Клиенты с разными версиями так себя ведут (и 3, и 4). На клиентах с 3 версией стоит ч/з координатор.

Share this post


Link to post
Share on other sites

могу предположить, что поможет обновление до версии 3.5, если такой возможности нет, то попробуйте поиграть параметрами ( время жизни тср-соединения после создания и время жизни установленного тср-соединения) один из параметров прописан в iplir.conf, а второй вроде в firewall.conf. Более точно в документации гляньте лучше.

Share this post


Link to post
Share on other sites

Обновиться возможности нет.

время жизни по умолчанию 60 минут, не стал менять.

Попробовал выставить mssdecrease, дошёл до 80 с шагом 10 - результата 0.

Кстати, забыл сказать, если в сети 2 разместить место без vipnet клиента (в фаерволе пакеты станут уже попадать в цепочку форвард, а не туннель), то на нём таких проблем уже не наблюдается.

Share this post


Link to post
Share on other sites

можете на клиенте версии 3.2 выставить тип межсетевого экрана с динамической трансляцией адресов и галочку весь трафик с внешними узлами направлять через координатор.

Что-то поменяется?

Share this post


Link to post
Share on other sites

Попробовал и с динамической, динамической+ч/з координатор, просто координатор, и вообще не использовать - результат один и тот же...

Share this post


Link to post
Share on other sites

В журналах координатора как смотрите?

Что указываете источником что назначением?

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

Share this post


Link to post
Share on other sites

Извиняюсь за долгий ответ.

В 20.12.2017 в 02:04, KIV сказал:

Почему нет возможности обновить ПО?

ТП кончилась, пока не продлили. Да и что даст обновление? Новая версия координатора, там точно такие проблемы исправлены? (знать бы ещё причину этих проблем). А клиенты имеют такие проблемы что с vipnet client 3, что с 4 версиями (лицензия позволяет поставить vipnet client 4.2)

В 19.12.2017 в 17:25, Rinya сказал:

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

Пробовал по всякому - везде всё хорошо и пропущено.

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

Проблема на***ается как вин сервер 2008/2012, так и на линукс серверах.

Про смену ip клиента из сети 2 я уже писал, так же и если пустить клиента из сети 1 напрямую в сеть 2, выдав ему адрес из сети 2, то связь есть.

Ну и, конечно, поставив vipnet client на клиента из сети 1 и пустить в сеть 2, тоже всё работает. Но такая схема мне не подходит, необходимо туннелировать.

Share this post


Link to post
Share on other sites
В 18.12.2017 в 14:55, w03zd8rc сказал:

ПАК - координатор HW1000
Сеть 2 - клиенты с випнет клиентом, шлюз у них НЕ ПАК.
Сеть 1 - клиенты без випнет клиента, изолированы своей приватной сетью, в интернет и прочие места (кроме своей приватной сети) ходят через ПАК. Соответственно, на ПАК прописаны в туннеле, сеть 2 обращается к ним ч/з ПАК, как к туннелям.
... один клиент из сети 2 (назовём его К2) не может достучаться до одного клиента из сети 1 (К1). Причём не может достучаться только по одному порту

Тип шлюза у HW1000 какой? Динамика, статика, без шлюза?
Другая железка перед ним есть или на одном из интерфейсов HW1000 поднят интернетовский адрес, выданный вам провайдером?

Что используется на шлюзе "Сеть 1"?

Share this post


Link to post
Share on other sites

Координатор напрямую одним интерфейсом смотрит в сеть 1, другим в сеть 2. Интерфейс в сети 1 в 4 режиме, во 2й в 3м. Координатор в режиме со статической трансляцией, в интернет не смотрит напрямую, работает через нат (межсетевые взаимодействия есть и исправно работают).

В сети 1 шлюзом является сам координатор, в сети 2 маршрутизатор в той же сети.

Share this post


Link to post
Share on other sites
5 часов назад, w03zd8rc сказал:

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

А шлюзовой NAT сети1 порты пробрасывает на координатор этой сети? А кто NAT-ит сеть2?
Просто первое, что приходит в голову при вашем описании - проблемы NAT-ирования. И основных вариантов - два: или режим трансляции координатора не соответствует реальной жизни или одному из NAT-ов тупо не хватает ресурсов/интеллекта.

Share this post


Link to post
Share on other sites
1 час назад, basid сказал:

А шлюзовой NAT сети1 порты пробрасывает на координатор этой сети? А кто NAT-ит сеть2?

Между сетью 1 и 2 нет ната: шлюзом для сети 1 выступает координатор, который, в соответствии с правилами туннелирования и форварда пропускает или нет пакеты дальше; в секции у координатора прописаны клиенты из сети 1 в туннелях; клиенты из сети 2 на клиентов из сети 1 стучатся как на туннелируемые адреса координатором. Координатор в связях у клиентов сети 2 есть, соединения разрешены. Нат в моём случае не затрагивает взаимодействие сети 1 и 2.

Share this post


Link to post
Share on other sites

Только  К2 стабильно отваливается? Другие нет?

Глупо спрашивать - пробовали переключать  К2 в другую розетку?

Я помню как долго были не понятки, почему то РДП только пропадёт то только печать и только на определённых ПК... в итоге методом логического исключения и перестановки, оказалось простой вроде "тупой" свич, начал вот такие финтиплюшки выдавать - видно поумнел и решил заделаться супер умным МЭ :-)

Это было "забавно", хотя изначально идеи мои как всегда обсмеять только могли :-)))

Share this post


Link to post
Share on other sites
9 часов назад, w03zd8rc сказал:

Между сетью 1 и 2 нет ната: шлюзом для сети 1 выступает координатор

Несколькими сообщениями ранее вы утверждали, что перед координатором находится какой-то другой шлюз.
Шлюз, естественно, не может "натировать между сетями 1 и 2". Но шлюз может (обычно - будет) NAT-ить сеть1. Если на нём не настроен проброс UDP на координатор - ваша конструкция имеет полное право поглюкивать.
Аналогично, шлюзом сети2 может быть другая железка, которая тоже имеет право поглюкивать, но уже по другим причинам.

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

Share this post


Link to post
Share on other sites
14 минут назад, Vintik сказал:

Это было "забавно", хотя изначально идеи мои как всегда обсмеять только могли :-)))

Гораздо чаще "кривенький NAT" можно обойти, если выдать каждому ViPNet-клиенту по уникальному порту инкапсуляции.
Или, что сильно дороже - установить на каждой площадке по координатору.

Share this post


Link to post
Share on other sites
7 часов назад, basid сказал:

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

это для выхода в интернет, для межсетевых взаимодействий. В сети же смотрит прямиком своими интерфейсами.

В сети 1 кроме клиентов и координатора вообще ничего нет - координатор и шлюз для клиентов.

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

Только  К2 стабильно отваливается? Другие нет?

Глупо спрашивать - пробовали переключать  К2 в другую розетку?

В сети 1 (20 клиентов) половина клиентов так себя ведут, с "избранными" из сети 2 (150 клиентов) - пока замечено только около 5-8 клиентов.

В сети 1 поведение такое как для виртуальных машин, так и для физических, разные циски.

Есть 2й координатор в режиме файловера - переключал, поведение тоже.

 

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.