Jump to content

Recommended Posts

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

Есть HW1000 доступный со стороны интернет по постоянному внешнему IP адресу через NAT со статическими правилами. В ЦУС для него добавлена строка вида S: IP адрес (то есть он туннелирует некоторый открытый узел). Для удаленного клиента этот координатор доступен. Туннелируемый узел в свою очередь доступен для координатора, а вот для удаленного клиента нет. В настройках фильтрации туннелируемого трафика стоит разрешающее правило по умолчанию. Подскажите, что нужно чтобы удаленный клиент все таки увидел туннелируемы ресурс?

Share this post


Link to post
Share on other sites

У клиента , для начала , проверить - клик на координатор ,появилась ли вкладка "Туннель" ..сама по себе .. если нет- ручную прописывать этот IP , добавить.

Share this post


Link to post
Share on other sites

У клиента , для начала , проверить - клик на координатор ,появилась ли вкладка "Туннель" ..сама по себе .. если нет- ручную прописывать этот IP , добавить.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Если я правильно понял, то:

1. Пример rule= num 1 proto any from 10.0.0.2-10.0.0.5(virtip) to anyip change src=192.168.1.25(координатора):dynamic

2. Чет не понял, наверно хватит маршрут прописать

Share this post


Link to post
Share on other sites

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

Конечно. В сети (на ядре или маршрутизаторе) пропишите что 10.0.0/24 (для примера) доступен через координатор. И еще, диапазон виртуальников можно выбрать собственный.

Share this post


Link to post
Share on other sites

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

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

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

На тунелируемом узле напишите статический мартшрут на координатор для виртуального ip адреса удаленного клиента, для чего в командной строке windows, запущенной от имени администратора, напишите команду типа: route add <виртуальный адрес удаленного клиента> mask 255.255.255.255 <ip адрес координатора>

или на вашем шлюзе по умолчанию напишите аналогичный статический маршрут

Share this post


Link to post
Share on other sites

Есть локальная сеть с n-количеством ПК

Все они попадают в защищенную сеть, через 1 шлюз.

Сам шлюз - ip-адрес, закреплен за одним из портов координатора. Т.е. пакеты из открытой сети приходят на этот порт и дальше идут в защищённую сеть.

Вопрос:

Подскажите, пожалуйста, что считать туннеллируемым соединением с точки зрения координатора: все множество ПК со своими внутренними адресами (192.168) или 1 адрес этого порта (шлюза)?

 

Спасибо.

Share this post


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

Есть локальная сеть с n-количеством ПК

Все они попадают в защищенную сеть, через 1 шлюз.

Сам шлюз - ip-адрес, закреплен за одним из портов координатора. Т.е. пакеты из открытой сети приходят на этот порт и дальше идут в защищённую сеть.

Вопрос:

Подскажите, пожалуйста, что считать туннеллируемым соединением с точки зрения координатора: все множество ПК со своими внутренними адресами (192.168) или 1 адрес этого порта (шлюза)?

 

Спасибо.

Вендор не дает такого определения.

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

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

Share this post


Link to post
Share on other sites
12 минут назад, R.Sheyn сказал:

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

Но вот что считать клиентом?

Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2...

вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля?

Share this post


Link to post
Share on other sites

Насколько я помню настройки, туннель делается до целевого хоста открытой сети.

Количество клиентом, одновременно подключающихся к целевому хосту, ограничено, вроде, только доступными ресурсами.

Share this post


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

Но вот что считать клиентом?

Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2...

вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля?

 

18 часов назад, sivantalex сказал:

Но вот что считать клиентом?

Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2...

вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля?

Если вспомнить как работает udp протокол, то ответ на вопрос станет понятен. Вообще не совсем правильно объяснять туннелирование как туннель в горах(это самое распространенное объяснение). Скорее это как такси. Для вас путешествие из точки А в точку Б, а для транспортного протокола(водителя) это выбор маршрута, маршрутизация.

Share this post


Link to post
Share on other sites

 

В 03.02.2019 в 08:29, R.Sheyn сказал:

туннелированное соединение

 Нет такого ограничения в координаторе, не по соединениям он ограничивает.

Есть "ip-адрес туннелируемого ресурса". Вот именно этот параметр и учитывается. Обратились с ip-адреса туннеля на другой туннель или клиент, счетчик туннелей  на координаторе увеличился на единицу. Теперь можно устанавливать хоть 100 соеденений с этого адреса, хоть 1000, без разницы.

Share this post


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

 

 Нет такого ограничения в координаторе, не по соединениям он ограничивает.

Есть "ip-адрес туннелируемого ресурса". Вот именно этот параметр и учитывается. Обратились с ip-адреса туннеля на другой туннель или клиент, счетчик туннелей  на координаторе увеличился на единицу. Теперь можно устанавливать хоть 100 соеденений с этого адреса, хоть 1000, без разницы.

Да. Это понятно, но судя по риторике вопроса человека интересует не столько терминология випнета, сколько общая теория.

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.