Jump to content

Search the Community

Showing results for tags 'туннелирование'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Продуктовый ряд ViPNet
    • Общие вопросы по продуктовому ряду ViPNet для корпоративных пользователей
    • Общие вопросы по программным решениям ViPNet для индивидуальных пользователей
    • Общие вопросы по продуктовой линейке ViPNet PKI
    • Пожелания к разработчикам ПО ViPNet
    • Пользовательские интерфейсы продуктов ViPNet
  • Бета-тестирование продуктов ViPNet
    • ViPNet Client/Coordinator x64
    • ViPNet Custom Windows
    • ViPNet Office Firewall Windows
    • ViPNet Office Firewall Linux
    • ViPNet Safe Disk
    • ViPNet Personal Firewall
    • ViPNet CSP 4.х
    • ViPNet Java Crypto SDK

Calendars

  • Основной календарь

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Интересы

Found 9 results

  1. Здравствуйте. Собственно, есть две сети ViPNet, между ними установлено межсетевое взаимодействие и все бы было хорошо, если бы не возникла необходимость сделать так, чтобы с туннелируемых компьютеров сети 001 (например, Тунель 01 сети 001) можно было попасть на туннели сети 002 (например, Тунель 02 сети 002). Реально ли это реализовать такое средствами ViPNet (не внутри одной випнет сети, а из туннелей одной випнет сетки в туннели другой)?
  2. Вопрос 1. ПАК туннелирует некие ip-адреса, далее "ресурсы 1" у этого ПАК в iplir.config в секции [id] другого программного координатора прописаны туннелируемые ресурсы, далее "ресурсы 2". Вопрос такой: когда некий узел обращается к ПАК и хочет обратиться к "ресурсам 2", как поступит ПАК ? а) ПАК передаст пакет от узла программному координатору, потому что "увидит", что программный координатор туннелирует данный ресурс б) ПАК просто поступит с этим пакетом согласно своим правилам маршрутизации и фильтрам ? Вопрос 2. Обновили ПАК до версии 4. На ПАКе в журнале ip-пакетов (iplir view) фиксируется только малая часть пакетов и у всех этих пакетов стоит флаг "D" -drop. Другими словами мы точно знаем, что данный ПАК успешно туннелирует один из ресурсов для нескольких узлов vipnet, но этого не отображается в журнале. в журнале только скудная кучка пакетов и все с флагом "d". Такое ощущение, что журнал настроен на отображение не всех пакетов, но только drop'нутых. ВОпрос: Как включить журналирование всех пакетов или это вообще можно трактовать как сбойная работа ПАК?
  3. Здравствуйте. Начали (пока ТОЛЬКО начали) создавать ViPNet-сеть: Администратор, HW-1000, два туннелируемых ресурса. Всё работало хорошо, до первого выключения всех машин - тупо свет отключили на пару часов. После запустили машины, ViPNet'ы работают, опросы идут. А вот туннелируемые ресурсы не работают - с них опрос на ViPNet ресурсы не идет. При этом, ни на одной машине настройки не сбились. Ну, собственно, долгое шаманство по началу ни к чему не приводило... Но потом мы эксперимента ради добавили новый туннель в ЦУСе (который не планируется использовать) и разослали справочники - туннели заработали... Убрали новый туннель, разослали справочники - опять все работает. Прошло несколько дней, возникла необходимость перенести машины в другой кабинет. Перенесли, включили, опять туннели не работают! Разослали справочники с новым туннелем (который не планируется использовать) - все заработало. Кому-нибудь доводилось сталкиваться с такой или подобной проблемой?
  4. День добрый, извиняюсь, если такая тема уже существует. А можно ли в виндовом Vipnet Client для некоторых туннелируемых адресов использовать виртуальный адрес а для некоторых реальный?
  5. Здравствуйте, коллеги! Схема сети Вопросы к знатокам и любителям ПО ViPNet: 1. Должен ли пинговать клиент внутренний адрес координатора (192.168.10.101)? На данный момент не пингует. 2. Клиент не получает ответов от туннелируемого сервера, хотя в журнале координатора на него возвращаются Echo reply от этого сервера, в журнале координатора это фиксируется. В журнале клиента входящих пакетов нет. Где копать? 3. Есть ли основания сваливать вину на PPPOE? Исходные данные: 1. Версии, билды клиента и координатора одинаковые, везде отключены брандмауэры Windows, прокси-серверов и внешних МСЭ нигде нет 2. Координатор: Win7, нет антивирусного ПО, пингует всё, режим 4, прописан IP туннеля 3. Клиент: Win7, пингует координатор по внешнему белому IP, режим 4, прописано, что координатор туннелирует сервер 4. Туннелируемый сервер: Win2003, пингует координатор, прописан статический маршрут до клиента 5. Координатор и туннелируемый сервер соединены напрямую кроссовым патчкордом 6. В координатор от провайдера приходит патчкорд, создаётся подключение PPPOE для белого IP (77.77.77.77 – для примера) 7. Переключение реальные/виртуальные адреса картины не меняет 8. Замена туннелируемого сервера на другую машину картины также не меняет Лог с координатора: Клиент-Сервер : 11.0.0.11 -> 192.168.10.100 - 45 - зашифрован (расшифрован) пакет туннелируемого ресурса Сервер-Клиент: 192.168.10.100 -> 11.0.0.11 - 63 - пакет пропущен фильтром для туннелируемых ресурсов Приветствуются любые ответы и предположения
  6. Всем Доброго дня! Имеется сеть, представленная на схеме выше. Комп1 и Комп2 находится в одной сети, в этой же сети находится сервер, с которым работают компы 1 и 2. К серверу компы подключаются через координатор HW100. Компы 3, 4, 5 - находятся в регионах и также работают с сервером. Вопрос такой: можно ли с учётом такой схемы и установленного на компах ПО VipNet, организовать защищённый канал связи между Комп3-Сервер, Комп4-Сервер, Комп5-Сервер? // С ПАК Координаторами да и вообще с технологией VipNet по сути не имел дела
  7. Доброго времени суток. Прошу помощи. Имеется такая схема: http://webfile.ru/6654397 HW1000 используется для туннелирования трафика от незащищенных компьютеров, находящихся в подсети 10.192.69.0/28. Задача: организовать защищенное соединение до ресурса, находящегося за Координатором. В ЦУСе для Координатора прописано туннелировать 10.192.64.149. В настройках HW1000 прописано туннелировать 10.192.69.10. Координатор для HW1000 - внешний ViPNet-прокси. 1. Если на 10.192.69.10 задать шлюзом по умолчанию 10.192.69.14, то все работает, страница с 10.192.64.149 грузится (трафик не шифруется), вот журнал с Координатора: http://webfile.ru/6654399 Какие настройки задать на Координаторе, чтобы исключить возможность соединения с туннелируемым ресурсом без шифрования трафика? 2. Если на 10.192.69.10 задать шлюзом по умолчанию 10.192.69.12 (HW1000), то страница с 10.192.64.149 перестает грузиться (трафик шифруется), вот журнал с Координатора: http://webfile.ru/6654401 и с HW1000: http://webfile.ru/6654402 Смущает последняя картинка. Насколько я понимаю, HW1000 не шлет расшифрованную страницу на 192.10.69.10. Где копать? Спасибо.
  8. Уважаемые пользователи сетей ViPNet! На сайт выложена статья вице-президента ОАО "ИнфоТеКС" "В.В. Игнатова Принципы маршрутизации и преобразования IP-трафика в VPN-сети, созданной с использованием технологии ViPNet". Статью можно скачать по ссылке http://www.infotecs....ail.php?ID=8633
  9. Доброго времени суток. Сетевое взаимодействие осуществляется между Гол.компанией и филиалами (10). В головной компании установлен координатор версии 3.2(9_11025), который предоставляет доступ к серверам приложений, туннелируя эти ресурсы. В нашем филиале установлено 1 раб. место администратора (администратор, клиент) и 1 сервер (координатор). Версия администратора, клиента и координатора - 3.1(1_5056). Координатор не стоит на границе сети, а находится за NATом (DLink router), который и разделяет сети. На роутере осуществлен проброс портов UDP 2046-2047, 55777 и TCP 5000-5003 по адресу внешнего интерфейса координатора. К внутреннему интерфейсу координатора подключено 1 защищенное раб. место (ЦУС, УКЦ, клиент] и одно незащищенное раб. место, которое туннелируется координатором. Необходимо осуществить доступ с рабочих мест нашей внутренней сети к ресурсам гол. компании. Что имеем на сегодняшний день: 1) Межсетевое взаимодействие между координаторами установлено. Доступ к ресурсам гол. компании разрешен. 2) С нашего координатора мы видим нашего клиента и координатор головной компании. Связь установлена со всеми узлами. Доступ к ресурсам координатора гол. компании есть (ping идет и по журналам видна вся цепочка, как в прямом, так и в обратном направлении). 3) С нашего защ. рабочего места мы видим свой координатор и координатор гол. компании, но при проверке связи с координатором гол. компании - связь не устанавливается. Так же нет доступа к ресурсам гол. компании. Ping по адресам серверов приложений не идет. 4) С нашего незащ. рабочего места, которое туннелируется нашим координатором, так же нет доступа к ресурсам гол. компании. Ping по адресам серверов приложений не идет. Уже вроде все перепробовал, даже ставил наш координатор на границу сети. Параметры нашей сети: DLink router WAN: IP: 84.204.100.100 GW:84.204.100.1 LAN: IP: 192.168.0.1 ports: UDP 2046-2047, 55777 и TCP 5000-5003 ---> 192.168.0.50 (адр. внешн. интерфейса координатора) Координатор Внешн. интерфейс: IP: 192.168.0.50/24 GW: 192.168.0.1 Внутр. интерфейс: IP: 192.168.1.1 **настройки в ЦУСе: E:192.160.0.50-84.204.100.100:OUT S:192.168.1.4 Защ. раб. место (администратор): IP: 192.168.1.10 GW: 192.168.1.1 Неащ. раб. место (туннелируемое): IP: 192.168.1.4 GW: 192.168.1.1 Сисадмин головной компании порекомендовал осуществить переход на клиента и координатор версии (3.2(9_11025)), но у меня нет уверенности, что переход на новую версию что то изменит. Вопрос: 1) Как по журналам, установить на каком этапе теряются пакеты, или какие настройки проверить, интуитивно чувствую, что дело не в версионности? 2) Как осуществить переход на клиента и координатор версии (3.2(9_11025)), и не будет ли конфликтов с ЦУС и УКЦ старой версии? Премного благодарен - начинающий.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.