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

Поиск в системе

Результаты поиска по тегам 'NAT'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип контента


Форумы

  • Продуктовый ряд 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

Искать результаты в...

Искать результаты, которые...


Дата создания

  • Начать

    Конец


Последнее обновление

  • Начать

    Конец


Фильтр по количеству...

Зарегистрирован

  • Начать

    Конец


Группа


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Интересы

Найдено 16 результатов

  1. Есть локальная сеть за координатором, на одной из машин данной сети установили vipnet клиент, который должен связываться и работать с другим координатором который к нам никак не относится. На нашем координаторе через который все выходят в интернет, был дан доступ на фаере и прописаны правила нат до адресов того координатора, но соединения нет, а в журнале видим пакеты дропаются с пометкой "9-Неизвестный идентификатор сетевого узла". У нас есть и другие ресурсы которые прописаны аналогично, и работают без проблем. Проблема только с vipnet.
  2. Здравствуйте. Не могу разобраться с настройкой NAT на hw100. Сеттинг такой: eth0 - DHCP, например, 192.168.9.100 eth1 - static, 10.3.37.1/24 В свойствах моего узла tunnel 10.3.37.1-10.3.37.254. Пробовал и 10.3.37.2-10.3.37.254. Удалённый координатор не знает про мою подсеть 10.3.37.0/24, то есть должен работать NAT. Добавлено правило NAT firewall nat add src @any dst @any change src auto Туннелируемая подсеть за удалённым коодинатором 10.4.105.0/24 с самого моего координатора пингуется: и inet iping и iplir ping того координатора. С хостов в локальной подсети (открытый трафик) 10.3.370/24 открытые ресурсы доступны (то есть NAT срабатывает), а вот подсеть 10.4.105.0/24 недоступна. При этом, в журнале пакетов, например, исходящий ICMP от адреса 10.3.37.2 отображается в событии 63 на eth1, затем в событии 45, ответный - в событии 40, для получателя 192.168.9.100 но у всех Трансляция-нетранслированный. То есть вроде бы со связанностью нормально, удалённый узел увидел и ответил. Но этот ICMP не доходит до 10.3.37.2, в журнале на eth1 нет ICMP пакета для 10.3.37.2 Вопрос: как настроить NAT для того, чтобы пакеты из локальной подсети 10.3.37.0/24 для туннелируемых адресов попадали тоже под NAT? Точнее, чтобы ответы попадали в NAT?
  3. Добрый день. При попытке зайти на сервер по RDP, на котором установлен Vipnet Client 4.3 (2.46794), падает служба ViPNet NAT Proxy с ошибкой: Это происходит, когда включена защита сети. Причем со стороны клиента на секунду мелькает авторизация на сервере. Потом данная служба падает, и RDP подключения недоступны. Порт 3389 даже по телнету не отвечает. Если отключить защиту - то RDP пускает без проблем.
  4. Здравствуйте, появилось необходимость использовать nat, но вот настроить не получается. Есть координатор с двумя интерфейсами 192.168.0.107 и 85.143.200.7, тунель к серверу 172.17.3.78 , необходимо наладить двухсторонний доступ к серверу 10.128.66.207 находящемуся за своим координатором. Нужна именно трансляция по определенному порту , чтобы на удаленном сервере был доступен веб интерфейс сервера по адресу http:85.143.200.7:56789 к примеру. После поиска в инете пришел к такому [nat] rule= num 2 proto any from anyip to 85.143.200.7 change src=172.17.3.78 [forward] rule=num 1 proto any from 10.128.66.207 to 172.17.3.78 pass Но как прописать трансляцию по определенному порту я так и не понял Буду очень признателен , если кто-нибудь подскажет что же делать в этом случае
  5. Добрый день! Есть два координатора, за каждым координатором есть по незащищённому узлу. Координаторы видят друг друга нормально. Компьютер 2 с випнет клиентом, 1 и 3 без. В каждой сети есть свой шлюз, соответственно ПАК-1 и ПАК-2 не являются шлюзами для компьютеров. На ПАК-2 прописан тоннель в своей секции (соответственно, на ПАК-1 в секции ПАК-2 он тоже есть) tunnel= 192.168.1.2-192.168.1.2 to 192.168.1.2-192.168.1.2 На ПАК-1 нет возможности сделать тоннель до компьютера 1 по реальному адресу, поэтому пытаюсь сделать через нат. Соответственно, пишу в секции [nat] фаервола следующее: rule= num 1 proto any from anyip to 192.168.0.2 change dst=192.0.0.2 rule= num 2 proto any from 192.168.0.2 to anyip change src=192.0.0.2 Далее на ПАК-1 в своей секции [id] и на ПАК-2 в секции ПАК-1 пишу: tunnel= 192.0.0.2-192.0.0.2 to 192.0.0.2-192.0.0.2 На компьютере 3 пишу маршрут, что 192.0.0.2 через ПАК-2 route add 192.0.0.2 mask 255.255.255.255 192.168.1.1 Ну и, на последок, на компьютере 1 прописываю маршрут до компьютера 3 route add 192.168.1.2 mask 255.255.255.255 192.168.0.1 В фаерволе общение между всеми ними разрешено, ПАК-1: [forward] rule= num 1 proto any from (192.168.0.2,192.0.0.2) to 192.168.1.2 pass rule= num 2 proto any from 192.168.1.2 to (192.168.0.2,192.0.0.2) pass [tunnel] rule= num 1 proto any from (192.168.0.2,192.0.0.2) to 0x1000002 pass rule= num 2 proto any from 0x1000002 to (192.168.0.2,192.0.0.2) pass rule= num 3 proto any from 0x0000002 to 192.168.1.2 pass rule= num 4 proto any from 192.168.1.2 to 0x0000002 pass На ПАК-2 всё разрешено. Что получаю на выходе: Компьютер 2 видит компьютер 3, и наоборот. Компьютер 3 видит компьютер 1 (по адресу 192.0.0.2), а вот компьютер 1 не видит компьютер 3. По журналу пакетов ПАК-1 классифицирует их как транзитный пакет, хотя пакеты от компьютера 3 (и ответы на них) как локальный пакет.
  6. Здравствуйте. Имеется две vipnet сети, между ними построено межсетевое взаимодействие. На Vipnet_1 и Vipnet_2 есть одинаковые туннели в сети 10.3.x.y/16 Задача стоит следующая, предоставить узлам находящимся за vipnet_1-1 доступ к серверу 10.62.30.1 Подскажите как можно выполнить данную задачу на оборудовании HW 2000 ver 3 (Vipnet_1) и HW100B (Vipnet_1-1) Возможно ли организовать на Vipnet_1 sNAT с последующей отправкой пакета в туннель? Если данное действие возможно то можете привести пример?
  7. Есть HW1000 к нему подключена локальная сеть и 2 VPN канала с удаленных областей с HW100. Нужно чтобы удаленные области имели выход в интернет и могли работать с сетью. Я добавил в NAT правило для подмены адреса для подсети удаленных областей и тогда происходит то что весь трафик проходящий через координатор HW1000(а весь трафик воле не волей и так идет через координатор) производит подмену и в итоге при обращении в локальную сеть трафик приходит уже с подменой. Да выход в интернет работает при таких настройках но мне требуется в локальной сети на серверах видеть реальный ip так как некоторые сервисы работают с ip и дают определенные возможности в зависимости от того от куда пришел трафик. Можно произвести настройку так чтобы подмена ip происходила только в определенных условиях например только при обращении к порту 80? Или чтобы подмена происходила только при обращении в сеть интернет?
  8. Добрый день! Подскажите, пожалуйста, с чем связанна и как исправить ошибку 105 при использование динамической трансляции? Конфигурация простая, кластер из двух hw2000 и хочется выпускать клиентов в интернет (клиенты=внутренняя сеть с пользователями) используя в качестве src адреса свой виртуальный внешний для кластера. Пишу [nat] rule = num1 proto any form 10.0.0.0-10.0.0.254 to anyip src=8.8.8.8:dynamic в логе получаю ошибку 105 В чем дело? Спасибо за реальную помощь. версия 3.2сертфицированная
  9. Здравствуйте. Есть координатор HW1000 (ver.3.2 728, Vipnet coordinator ver.: 3.7.3-5761 ), за которым расположен сервис, который надо опубликовать. На одном интерфейсе режим 3, и белый IP 83.246.Х.Х - для внешней сети. На другом интерфейсе режим 3 и серый ip 172.X.X.192 - для внутренней сети. Надо, чтобы из внешней сети при обращении на белый IP координатора осуществлялась трансляция на узел 172.X.Х.32 во внутренней сети (узел не в туннеле, Vipnet-Client не стоит). Прописываю правило в секции [nat] rule= num 1 proto tcp from anyip to 83.246.X.X:80 change dst=172.X.X.32:80 - все хорошо, пакеты пролетают до адресата. Но проблема в том, что узла 172.X.X.32 шлюз по умолчанию другой - не мой координатор, поэтому ответы обратно летят не ко мне, что приводит к рассинхронизации. Пробовал прописывать правило подмены источника на адрес интерфейса 172.X.X.192 (какими только способами не пробовал), но оно не срабатывает - src не подменяется. Вот как я писал (варианты): 1) rule= num 2 proto any from anyip to 172.X.X.32 change src=172.X.X.192:dynamic 2)rule= num 2 proto tcp from anyip to 172.X.X.32 change src=172.X.X.192:dynamic Пробовал другие варианты, какие только смог придумать. И общее правило пробовал: 3) rule= num 2 proto any from anyip to anyip change src=172.X.X.192:dynamic Не подменяется адрес источника и всё тут. А адрес назначения подменяется без проблем. Подскажите, пожалуйста, что я делаю не так.
  10. Доброго дня! Имеется крупная сеть, в центре стоит HW1000 (версия ПО - 3.3 (1099)) в кластере, вся сеть работает через Internet. На периферии расположены HW1000 (около 70 шт.), версии ПО - 2.6, 3,1, 3.3, 3,5, и несколько (~7 шт.) Coordinator Windows (3.1). Есть много клиентов но они в основном не включаются. 80% периферийных HW1000 работают в режиме с динамической трансляцией адресов , несколько со статикой без фикса и несколько со статикой и фиксом. Центр со статической трансляции без фикса. 1-я проблема заключается в том, что на периферийных HW1000 (с динамикой) периодически слетает параметр firewallip, но не слетает а меняется на внешний ip центрального HW1000. При этом не проходит проверка соединения iplir ping от периф.HW1000 до центрального и в обратном направлении. Соответственно и нет доступа к туннелируемым ресурсам центрального HW1000. 2-я проблема заключается в том что между периферийными координаторами также пропадает связь и не восстанавливается пока вручную не изменить firewallip (он в этот момент такой же как у центра) на периферийном HW1000. В основном все координаторы сети (за исключением 2-3) связаны между собой МСК и конечно, по типам коллективов. Вопрос, в чем может быть проблема, почему firewallip периферийного HW1000 меняется на ip центрального HW1000? Может проблема с МСК, т.к. координаторы могут и массово (15 из 70) сменить у себя [dynamic] -> firewallip, а могут по одиночке.
  11. Добрый день в hw1000 было вбито 6 правил,потом 5е правило удалили,есть ли где то в логах или ещё где нить найти что там было за правило?
  12. В центральном офисе hw1000 в режиме без использования межсетевого экрана (белый адрес на интерфейсе координатора). В филиалах hw100, к которому подключен сервер Windows, с поднятой службой "маршрутизация и удаленный доступ" в которой включен NAT, к серверу подключена локалка филиала с компьютерами. Все работает. Появились мобильные сотрудники, которым нужно работать и в сети филиала и на выезде со сторонним интернетом. На ноутбуки мобильных сотрудников поставили vipnet client 3.2 (11.21139). Vipnet client подключаются в локальную сеть филиала (та, что за серверов с nat). Возникла следующая проблема, которую никак не могу побороть, а именно некоторые vipnet client успешно подключаются к координатору центрального офиса, другие при тех же настройках не видят центрального координатора, вернее координатор не доступен. Схема сети во вложении. Vipnet client настроены в режиме с динамической трансляцией, сервер ip адресов - центральный координаторhw1000, координатор для организации соединений с внешними узлами - координинатор филиала. Не могу никак понять, почему один клиент работает, другой нет. Пробовал на неработающих клиентах менять настройки по всякому, в журнале клиента вижу "40 - пропущен защифрованный ip пакет" реального адреса ноутбука, ответа нет. На координаторе филиала вижу отправленные пакеты, а также полученные пакеты, в которых стоит id vipnet client, но IP адрес внешнего интерфейса сервера с nat, а не виртуальный адрес клиента. На центральном координаторе полученные пакеты и ответы на виртуальный адрес. Уважаемые форумчане, подскажите правильные настройки. vipnet сеть.pdf
  13. Здравствуйте! Есть сеть вот с такой схемой: Интернет подключен к координатору A и координатору D. Координаторы B и координаторы C должны ходить в интернет через координатор A. Все координаторы выполняют функции маршрутизаторов. Все подсети 10.77.*.* являются внутренними, трафик между ними должен шифроваться координаторами. Трафик, который идет в интернет, шифровать не обязательно. Координаторы B и C соединены между собой и с координатором A через сеть IP-VPN, организуемую провайдером. Т. е. для нас это получается небезопасная сеть, и трафик при передаче через нее должен шифроваться. Компьютеры, находящиеся внутри сетей, должны видеть компьютеры из любой указанной сети так, как будто они работают в одной локальной сети. Сейчас получается так: компьютеры из сети координатора C не видят компьютеры в сети координатора A при включенном NAT на координаторе A. Если NAT выключить, то пропадает интернет (у всех, кто подключен через координатор А), но начинаются видеться компьютеры из сети координатора А. Наши координаторы имеют 4 порта. Можно ли как-то разделить по портам внутреннюю и внешнюю сеть (чтобы они втыкались в разные порты)? До координаторов сети работали в прозрачном режиме, т.е. провод провайдера втыкался в наш коммутатор на каждой площадке, а там, где расположен координатор А, было два провода - локальная сеть и отдельно интернет. Хочется поставить координаторы на "бутылочное горлышко" каждой площадки (как сейчас установлены координаторы A и D) и чтобы все пользователи работали через них в прозрачном для пользователей режиме. Сейчас не можем придумать иного способа, кроме как отключить NAT на координаторе A и поставить между ним и интернетом проксю с натом, но это точно не добавит сети надежности, а нам не упростит администрирование. Существуют ли способы реализовать шифрование межсетевого трафика и выход в интернет силами только координаторов?
  14. Здравствуйте. Прошу помочь решить проблему,решение которой я никак не найду. есть следующая схема сети: Абоненты А и Б незащищённые. Абонент В защищён-на нём установлен випнет клиент. Сети 172.16.1.0/25 и 172.16.1.129/25 туннелируются. В настройках HW и Абонента В это указано. Для hw маршрутом по умолчанию является коммутатор, находящийся в сети 10.10.1.0/29. На HW1000 прописан статический маршрут к 2.2.2.2. АП Абонента В принадлежит СМ HW1000. В настройках Абонента В для HW1000, в графе с реальными IP указаны все три ip hw 1000. Так же указан ip межсетевого экрана - 1.1.1.1. И Адреса тунелируемых устройств - 172.16.1.0/25. На HW1000 в iplire,в своём блоке указана работа через межсетевой экран(usefirewall) и firewallip=1.1.1.1. Так же этот интерфейс указан как external. В блоке Абонента В я так же ставил usefirewall=on и firewallip=2.2.2.2, но при запуске iplir'a firewallip меняется на 1.1.1.1. в итоге в блоке с Абонентом В указывается ip=192.168.1.x, acessip=192.168.1.x, firewallip=1.1.1.1, и proxyid= id СМ HW1000. При ICMP запросе от Абонента В до Абонента А в журнале Абонента В отображается зашифрованный пакет от АП Абонента В до СМ HW1000. В журнале HW1000 этот пакет тоже отображается. причём source ip - частный ip Абонента В. Но reply icmp отправляется hw так же на частный IP адрес Абонента В. И соответственно делает он это на шлюз по умолчанию. Подскажите, пожалуйста, как указать HW1000 что Абонент В находится за 2.2.2.2? Думал что нужно нат использовать, но там нет возможности указывать Ip адрес получателя-только anyip. Т.е. если транслировать, то транслировать всё, что приходит на СМ. В ЦУСе, может что-то не так сконфигурено?У меня не хватает фантазии,чтобы понять в какую сторону копать
  15. Добрый день! Пытаюсь настроить проброс айпи-адреса как показано на картинке: Координатор А тунеллирует ресурс 10.Х.Х.А, координатор Б смотрит в сеть 10.Y.Y.0/24 интерфейсом eth1 с адресом 10.Y.Y.A. Конечная цель: любой ip-пакет, отправленный на 10.Y.Y.B долетает до 10.X.X.A. В ходе долгих экспериментов с тунеллированием выяснил: если 1) прописать в iplir config на Координаторе А: в собственной секции id: tunnel= 10.X.X.A-10.X.X.A to 10.X.X.A-10.X.X.A в секции id Координатора Б: tunnel= 10.Y.Y.B-10.Y.Y.B to 10.X.X.A-10.X.X.A на Координаторе Б: в собственной секции id: tunnel= 10.Y.Y.B-10.Y.Y.B to 10.Y.Y.B-10.Y.Y.B к секции id координатора А: tunnel= 10.X.X.A-10.X.X.A to 10.Y.Y.B-10.Y.Y.B 2) прописать айпи 10.Y.Y.B в качестве дополнительного на интерфейс eth1 координатора Б 3) пустить пинги на 10.Y.Y.B с хоста 10.Y.Y.C (пинг будет успешен) 4) удалить дополнительный айпи адрес 10.Y.Y.B с интерфейса eth1 Координатора Б 5) быстро запустить iplir Проброс работает какое-то время, то есть icmp-пакеты, отправленные хостом 10.Y.Y.C на 10.Y.Y.B, в tcpdump хоста 10.X.X.A можно наблюдать: 18:48:40.169349 IP 10.Y.Y.C > 10.X.X.A: ICMP echo request, id 1, seq 4008, length 40 18:48:40.169658 IP 10.X.X.A > 10.Y.Y.C: ICMP echo reply, id 1, seq 4008, length 40 18:48:41.185221 IP 10.Y.Y.C > 10.X.X.A: ICMP echo request, id 1, seq 4009, length 40 18:48:41.185475 IP 10.X.X.A > 10.Y.Y.C: ICMP echo reply, id 1, seq 4009, length 40 Но не проходит и минуты, как сетевая связанность разрушается. Дело в ARP, если я просто прописываю туннель, то координатор Б не отвечает на ARP-запросы хоста 10.Y.Y.С касательно хоста 10.Y.Y.B. Но в то же время при прописанном дополнительном айпи-адресе 10.Y.Y.B на "Координаторе Б", туннель не подымается, при iplir start ругается на конфликт. Добавлю также, что пытался решить эту задачу при помощи dst-nat. Но, как написано в руководстве, dst-nat должен использоваться для проброса отдельных портов, а не IP-адресов целиком. И по факту ничего не работает даже tcpdump на "Координаторе Б" не видит icmp-пакетов или arp-запросов от 10.Y.Y.C на 10.Y.Y.B при прописанном дополнительном ip-адресе и включенном правиле nat num 50 proto any from anyip to 10.Y.Y.B change dst=10.X.X.A
  16. Доброе время суток. Уже 2ю неделю пытаюсь разными путями разобраться со следующей проблемой. Есть следующая (упрощенная) схема сети. Мне дали белый внешний ip и NATируют его на мой внутренний - 10.10.45.10 (cisco). На циске я публикую 2 порта - 80 (http) и UDP 55777 для VipNet. Публикация 80го порта прекрасно работает без каких-либо сбоев. Публикация 55777 не хочет работать ни в какую. Клиенты извне не видят координатор. Внутренние, конечно же, без проблем к нему цепляются. Немного технических подробностей: VipNet Coordinator 3.1 (2.6318), WindowsXP Prof SP3 (виртуалка, если это имеет значение). В журнале регистрации IP-пакетов есть странная (с моей т.зрения) строчка: Источник: 192.168.55.45 (шлюз) Назначение: 192.168.55.14 (VipNet) Протокол: ICMP Тип/код ICMP: 5-Redirect / 0-Redirect Datagram for the Network Событие отклонения: 34 - неподдерживаемый тип ICMP-сообщения. Антиспуфинг выключен (пробовал и включать), режим 4й (пока настраиваю). Подключение: со статической трансляцией адресов и зафиксировано внешний IP адрес - 213.234.ххх.yyy, обнаружение атак в обе стороны выключено. в ЦУСе в прописано следующее: E:192.168.55.14-213.234.***.yyy:55777 и 192.168.55.14 Теперь про cisco: публикую так: ip nat inside source list NAT interface FastEthernet0 overload # выход в интернет для машин ip nat inside source static udp 192.168.55.14 55777 interface FastEthernet0 55777 # VipNet ip nat inside source static tcp 192.168.55.3 80 interface FastEthernet0 80 # WEB Extended IP access list NAT 10 permit ip host 192.168.55.3 any (2 matches) 20 permit ip host 192.168.55.14 any (41 matches) 30 deny ip any any (8093 matches) Extended IP access list ХХХХ (для внешнего интерфейса, 10.10.45.10, было permit ip any any - результат тот же) 10 permit icmp any any (132 matches) 40 permit tcp any any eq www log (309 matches) 45 permit udp any any eq 55777 log (15604 matches) 60 deny ip any any (6144 matches) Extended IP access list YYYY ( для внутреннего интерфейса, 192.168.55.45, так же было permit ip any any ) 5 permit icmp any any (7134 matches) 10 permit ip host 192.168.55.3 any (222 matches) 20 permit ip host 192.168.55.14 any (130466 matches) 60 deny ip any any (168382 matches) Ну вот как-то так. В планах попробовать OS на координаторе переставить на Win2003 (от безысходности уже), либо, вынести координатор вообще в DMZ, и всех внутренних клиентов пускать через динамическое подключение через интернет (но это решение мне нравится меньше всего, хотя внутренних клиентов не очень много). Заранее спасибо.
×
×
  • Создать...

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

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