roman79 Опубликовано 29 Июня 2015 Жалоба Поделиться Опубликовано 29 Июня 2015 Здравствуйте.Есть HW1000 доступный со стороны интернет по постоянному внешнему IP адресу через NAT со статическими правилами. В ЦУС для него добавлена строка вида S: IP адрес (то есть он туннелирует некоторый открытый узел). Для удаленного клиента этот координатор доступен. Туннелируемый узел в свою очередь доступен для координатора, а вот для удаленного клиента нет. В настройках фильтрации туннелируемого трафика стоит разрешающее правило по умолчанию. Подскажите, что нужно чтобы удаленный клиент все таки увидел туннелируемы ресурс? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
diip Опубликовано 29 Июня 2015 Жалоба Поделиться Опубликовано 29 Июня 2015 У клиента , для начала , проверить - клик на координатор ,появилась ли вкладка "Туннель" ..сама по себе .. если нет- ручную прописывать этот IP , добавить. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
roman79 Опубликовано 29 Июня 2015 Автор Жалоба Поделиться Опубликовано 29 Июня 2015 У клиента , для начала , проверить - клик на координатор ,появилась ли вкладка "Туннель" ..сама по себе .. если нет- ручную прописывать этот IP , добавить.У клиента такая вкладка есть. IP адреса туннелируемых узлов там отображаются. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Vanish1990 Опубликовано 29 Июня 2015 Жалоба Поделиться Опубликовано 29 Июня 2015 Заходите под админом на клиента и смотрите журнал ip-пакетов - узла, координатора, между ними. По-моему очень хороший способ выявить проблему. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
roman79 Опубликовано 30 Июня 2015 Автор Жалоба Поделиться Опубликовано 30 Июня 2015 Заходите под админом на клиента и смотрите журнал ip-пакетов - узла, координатора, между ними. По-моему очень хороший способ выявить проблему.С удаленного клиента отправляем icmp пакет на туннелируемый узел (в журнале клиента это видно). На координатор этот пакет доходит, расшифровывается и направляется тунелируемому узлу, однако в качестве адреса источника указывается виртуальный IP адрес удаленного клиента, а координатор для тунелируемого узла не является шлюзом по умолчанию. Пакет доходит до туннелируемого узла и тот его отпровляет по дефолтному маршруту где он и пропадает.1. Как сделать, чтобы координатор в этом случае использовал трансляцию адресов (подменял виртуальный IP адрес удаленного клиента на реальный своего интерфейса который смотрит в сторону туннелируемого узла)?2. Можно ли обойтись без назначения шлюзом по умолчанию координатора, через который осуществляется доступ таким образом? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Vanish1990 Опубликовано 30 Июня 2015 Жалоба Поделиться Опубликовано 30 Июня 2015 С удаленного клиента отправляем 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(координатора):dynamic2. Чет не понял, наверно хватит маршрут прописать Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
AnTonN(c) Опубликовано 30 Июня 2015 Жалоба Поделиться Опубликовано 30 Июня 2015 >2. Можно ли обойтись без назначения шлюзом по умолчанию координатора, через который осуществляется доступ таким образом?Конечно. В сети (на ядре или маршрутизаторе) пропишите что 10.0.0/24 (для примера) доступен через координатор. И еще, диапазон виртуальников можно выбрать собственный. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
admiral62 Опубликовано 21 Октября 2015 Жалоба Поделиться Опубликовано 21 Октября 2015 С удаленного клиента отправляем icmp пакет на туннелируемый узел (в журнале клиента это видно). На координатор этот пакет доходит, расшифровывается и направляется тунелируемому узлу, однако в качестве адреса источника указывается виртуальный IP адрес удаленного клиента, а координатор для тунелируемого узла не является шлюзом по умолчанию. Пакет доходит до туннелируемого узла и тот его отпровляет по дефолтному маршруту где он и пропадает.1. Как сделать, чтобы координатор в этом случае использовал трансляцию адресов (подменял виртуальный IP адрес удаленного клиента на реальный своего интерфейса который смотрит в сторону туннелируемого узла)?2. Можно ли обойтись без назначения шлюзом по умолчанию координатора, через который осуществляется доступ таким образом?На тунелируемом узле напишите статический мартшрут на координатор для виртуального ip адреса удаленного клиента, для чего в командной строке windows, запущенной от имени администратора, напишите команду типа: route add <виртуальный адрес удаленного клиента> mask 255.255.255.255 <ip адрес координатора>или на вашем шлюзе по умолчанию напишите аналогичный статический маршрут Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
sivantalex Опубликовано 2 Февраля 2019 Жалоба Поделиться Опубликовано 2 Февраля 2019 Есть локальная сеть с n-количеством ПК Все они попадают в защищенную сеть, через 1 шлюз. Сам шлюз - ip-адрес, закреплен за одним из портов координатора. Т.е. пакеты из открытой сети приходят на этот порт и дальше идут в защищённую сеть. Вопрос: Подскажите, пожалуйста, что считать туннеллируемым соединением с точки зрения координатора: все множество ПК со своими внутренними адресами (192.168) или 1 адрес этого порта (шлюза)? Спасибо. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
R.Sheyn Опубликовано 2 Февраля 2019 Жалоба Поделиться Опубликовано 2 Февраля 2019 1 час назад, sivantalex сказал: Есть локальная сеть с n-количеством ПК Все они попадают в защищенную сеть, через 1 шлюз. Сам шлюз - ip-адрес, закреплен за одним из портов координатора. Т.е. пакеты из открытой сети приходят на этот порт и дальше идут в защищённую сеть. Вопрос: Подскажите, пожалуйста, что считать туннеллируемым соединением с точки зрения координатора: все множество ПК со своими внутренними адресами (192.168) или 1 адрес этого порта (шлюза)? Спасибо. Вендор не дает такого определения. С точки зрения элементарной логики, туннелируемое соединение, это соединение, которое туннелируется, т.е. попадает в туннель. Т.е. соединение например от клиента к серверу, которое проходит через туннель будет туннелируемым. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
sivantalex Опубликовано 2 Февраля 2019 Жалоба Поделиться Опубликовано 2 Февраля 2019 12 минут назад, R.Sheyn сказал: Т.е. соединение например от клиента к серверу, которое проходит через туннель будет туннелируемым. Но вот что считать клиентом? Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2... вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
basid Опубликовано 3 Февраля 2019 Жалоба Поделиться Опубликовано 3 Февраля 2019 Насколько я помню настройки, туннель делается до целевого хоста открытой сети. Количество клиентом, одновременно подключающихся к целевому хосту, ограничено, вроде, только доступными ресурсами. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
R.Sheyn Опубликовано 3 Февраля 2019 Жалоба Поделиться Опубликовано 3 Февраля 2019 18 часов назад, sivantalex сказал: Но вот что считать клиентом? Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2... вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля? 18 часов назад, sivantalex сказал: Но вот что считать клиентом? Я просто пытаюсь понять. Вот пришел трафик от 20 компов на 1 порт, но у них у всех 20 разных направлений. т.е. ресурсов. Но чтобы добраться до этих ресурсов - они выходят через другой, но также один порт координатора 1 идут в зашифрованном виде по открытым каналам, потом попадают на порт координатора 2... вот на координаторе 1 - всего одно туннелированное соединение или каждый локальный узел (ПК) требует своего туннеля? Если вспомнить как работает udp протокол, то ответ на вопрос станет понятен. Вообще не совсем правильно объяснять туннелирование как туннель в горах(это самое распространенное объяснение). Скорее это как такси. Для вас путешествие из точки А в точку Б, а для транспортного протокола(водителя) это выбор маршрута, маршрутизация. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
zero Опубликовано 4 Февраля 2019 Жалоба Поделиться Опубликовано 4 Февраля 2019 В 03.02.2019 в 08:29, R.Sheyn сказал: туннелированное соединение Нет такого ограничения в координаторе, не по соединениям он ограничивает. Есть "ip-адрес туннелируемого ресурса". Вот именно этот параметр и учитывается. Обратились с ip-адреса туннеля на другой туннель или клиент, счетчик туннелей на координаторе увеличился на единицу. Теперь можно устанавливать хоть 100 соеденений с этого адреса, хоть 1000, без разницы. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
R.Sheyn Опубликовано 4 Февраля 2019 Жалоба Поделиться Опубликовано 4 Февраля 2019 12 минут назад, zero сказал: Нет такого ограничения в координаторе, не по соединениям он ограничивает. Есть "ip-адрес туннелируемого ресурса". Вот именно этот параметр и учитывается. Обратились с ip-адреса туннеля на другой туннель или клиент, счетчик туннелей на координаторе увеличился на единицу. Теперь можно устанавливать хоть 100 соеденений с этого адреса, хоть 1000, без разницы. Да. Это понятно, но судя по риторике вопроса человека интересует не столько терминология випнета, сколько общая теория. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
sivantalex Опубликовано 7 Февраля 2019 Жалоба Поделиться Опубликовано 7 Февраля 2019 Спасибо, ребят. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.