Перейти к контенту

Рекомендуемые сообщения

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

Не работает туннель.... Все перерыл вроде

Нигде никаких брадмаузеров нет

Везде 4 режим (это пока)

Вот настройки

192.168.1.14 - 1с сервер, Windows 2012 R2 DataBase x64

VipNetClient 3.2, Windows 2008 R2 SP1 x64

VipNet coordinator 3.2, Windows 2008 R2 SP1 x64

Настройка ЦУС

Выделил 5 туннелей в ЦУС'е для координатора

Добавил такую строчку в ЦУСе S:192.168.1.14

Сформировал справочники

Разослал справочники

Настройки координатора

Он сьел справочники

Перезапустился

Туннель появился в списке IP адресов (в фильтре туннелей)

Фильтрация для туннелируемых узлов - разрешено все (все протоколы, все порты, все интерфейсы)

Настройка клиента

Добавил в СУ Координатора (вкладка туннели) IP адрес

Галка виртуальные IP адреса стоит

Галка Не туннелировать IP адреса в входящие в подсеть этого компьютера не стоит

В журналах все нормально т.е якобы все ходит.

В 3.1 с такими настройками все работало - как обновились начался такой писец....

Помогите пожалуйста

Ссылка на комментарий
Поделиться на других сайтах

Почему пакет от координатора до туннелироемого узла приходит с IP адресом 11.0.0.195????

Это виртуальный адрес удаленного клиента. Что за приколы???

Ссылка на комментарий
Поделиться на других сайтах

По видимому Координатор "видит" Клиента именно по виртуальному адресу 11.0.0.195.

Посмотрите на Координаторе под каким адресом он "видит" Клиента?

Ссылка на комментарий
Поделиться на других сайтах

По видимому Координатор "видит" Клиента именно по виртуальному адресу 11.0.0.195.

Посмотрите на Координаторе под каким адресом он "видит" Клиента?

Да. Виртуальный адрес. Но проблема в том что IP адреса у каждого СУ уникальный.

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

Все эти пакеты разруливать обратно до координатора как то не хорошо.

В снифере все видно. IP адреса не меняються.

Ув. Stratos где то писал что у однокарточного координатора могут быть проблемы с туннелированием.

Может у кого то есть решение данной проблемы?

Ссылка на комментарий
Поделиться на других сайтах

route -p add 11.0.0.0 mask 255.0.0.0 [iP координатора] mteric 10 if [интерфейс 1с сервера т.е 192.168.1.14 ]

Не работает.

Еще пробовал сделать координатор для туннелируемого узла основным шлюзом т.е 0.0.0.0 / 255.255.255.255 / 192.168.1.171 / 192.168.1.14 metric 10 - ноль реакции

192.168.1.171 - IP адрес координатора

Ссылка на комментарий
Поделиться на других сайтах

Динамический нат вам нужен

Тип трансляции - динамический

Внутренняя сеть - 192.168.1.14

Внешняя сеть - Автоматическое определение адреса

Ссылка на комментарий
Поделиться на других сайтах

Правило NAT должно быть таким, чтобы все исходящие пакеты (и соответственно трафик к туннелируемому серверу) шли от адреса Координатора.

Ссылка на комментарий
Поделиться на других сайтах

Правило NAT должно быть таким, чтобы все исходящие пакеты (и соответственно трафик к туннелируемому серверу) шли от адреса Координатора.

Аммм. А как это в Windows версии сделать??

Ссылка на комментарий
Поделиться на других сайтах

Не знаю как в Windows. Самому интересно )) Под рукой нет, чтобы попробовать.

На HW и под Linux всегда пишу так, если Координатор стоит внутри сетки и имеет один интерфейс:

rule= num 10 proto any from anyip to anyip change src=x.x.x.x:dynamic

x.x.x.x - это реальный адрес Координатора

В итоге все удаленные Клиенты нормально попадают на туннелируемые серваки.

Ссылка на комментарий
Поделиться на других сайтах

Не знаю как в Windows. Самому интересно )) Под рукой нет, чтобы попробовать.

На HW и под Linux всегда пишу так, если Координатор стоит внутри сетки и имеет один интерфейс:

rule= num 10 proto any from anyip to anyip change src=x.x.x.x:dynamic

x.x.x.x - это реальный адрес Координатора

В итоге все удаленные Клиенты нормально попадают на туннелируемые серваки.

netsh?? покопаю в эту сторону.

Отпишусь обязательно)

Ссылка на комментарий
Поделиться на других сайтах

В HW и Координаторах Linux это правило пишется в firewall.conf, в секции NAT.

Не получается совсем. Туннелируемый узел по прежнему видит все виртуальные ip адреса, и стабильно отправляет их в никуда.

Ссылка на комментарий
Поделиться на других сайтах

В HW и Координаторах Linux это правило пишется в firewall.conf, в секции NAT.

"rule= num 10 proto any from anyip to anyip change src=x.x.x.x:dynamic" - для Windows искал аналог этой команды. Не нашел. Помню что NetSh подобное мог. А как это делалось уже не помню.

Ссылка на комментарий
Поделиться на других сайтах

А не пробовали просто на координаторе виртуальные адреса СУ VipNet Клиентов на реальные переключить?

Ссылка на комментарий
Поделиться на других сайтах

А не пробовали просто на координаторе виртуальные адреса СУ VipNet Клиентов на реальные переключить?

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

Гость
Эта тема закрыта для публикации сообщений.
×
×
  • Создать...

Важная информация

Продолжая пользоваться сайтом вы принимаете Условия использования.