Туннелирование Открытых Узлов

[roman79]

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

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

[diip]

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

[roman79]

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

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

[Vanish1990]

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

[roman79]

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

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

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

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

[Vanish1990]

С удаленного клиента отправляем 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. Чет не понял, наверно хватит маршрут прописать

[AnTonN(c)]

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

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

[admiral62]

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

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

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

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

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

[sivantalex]

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

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

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

Вопрос:

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

 

Спасибо.

[R.Sheyn]

1 час назад, sivantalex сказал:

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

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

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

Вопрос:

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

 

Спасибо.

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

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

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

[sivantalex]

12 минут назад, R.Sheyn сказал:

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

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

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

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

[basid]

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

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

[R.Sheyn]

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

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

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

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

 

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

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

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

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

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

[zero]

 

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

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

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

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

[R.Sheyn]

12 минут назад, zero сказал:

 

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

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

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

[sivantalex]

Спасибо, ребят.