Не Проходят Пакеты Из Разных Подсетей 22 - Не Зашифрованый Ip Пакет

[Sanya]

И меються две подсети настроено тунелирование но при пинге или опросе пакеты не проходять в журнале стоит признак блокирован 22 не шифрованый ip пакет от сетевого узла в чем может быть проблема.

[slavanchuk]

Что за координаторы? Каких версий? Судя по всему, либо туннель не прописан толком, либо сетевые фильтры не прописаны должным образом.

[Sanya]

координатор 1 версии 3,1 ставил интерфейсы 4-5 режим на координаторе такая же картина разница в клиентах один версии 3,1 другой 3,2 но есть машина администратора к ней доступ есть

[slavanchuk]

  16.05.2013 в 10:50, Sanya сказал:

координатор 1 версии 3,1 ставил интерфейсы 4-5 режим на координаторе такая же картина разница в клиентах один версии 3,1 другой 3,2 но есть машина администратора к ней доступ есть

Так, а туннели вы как прописывали? Координатор windows, как я понял?

[Sanya]

Координатор windows. на координаторе ip адрес туннелируемых устройств 10.0.0.1 -10.0.0.254 все интерфейсы защищенные узлы vpn 600. все протоколы

транзитные фильтры 10.31.0.1 192.168.0.1

все протоколы

[slavanchuk]

  17.05.2013 в 06:17, Sanya сказал:

Координатор windows. на координаторе ip адрес туннелируемых устройств 10.0.0.1 -10.0.0.254 все интерфейсы защищенные узлы vpn 600. все протоколы

транзитные фильтры 10.31.0.1 192.168.0.1

все протоколы

А вы в ЦУС прописывали для данного координатора windows квоту на необходимое количество туннелируемых адресов? В противном случае они не будут туннелироваться, хотя всё и прописано.

[Sanya]

да там мамксимум стоит 13.

[slavanchuk]

Тогда вопрос - зачем вы столько адресов прописали, если всё равно только 13 туннелироваться смогут. И ещё Вы не ответили - вы через ЦУС прописывали или на самом координаторе?

[Sanya]

И в цусе прописан и на координаторе

[slavanchuk]

  20.05.2013 в 10:15, Sanya сказал:

И в цусе прописан и на координаторе

Кстати, у вас фигурируют ip-адреса 10.*.*.*. Это реальные адреса или виртуальные? Вы прописываете именно реальные адреса для туннелей? А виртуальные адреса у Вас из какого диапазона? Нет ли тут конфликта?

[Sanya]

да это реальные адреса. виртуальные 11 диапазон

[slavanchuk]

Ещё раз посмотрел на номер ошибки и закралось подозрение. Данный вид ошибки возникает, когда приходит открытый пакет от защищённого узла (то есть, от узла, на котором стоит или стоял vipnet). Скорее всего, на одном из сетевых узлов в координаторе стоит данный ip-адрес. Такое может быть при DHCP в сети или если на данном узле (или с данного IP-адреса) раньше стоял VipNet. Проидитесь по всем узлам и удалите из настроек данные адреса - ошибка блокировки уйдёт.

[Sanya]

весь смысл что в том что стоит клиент но он другой сети клиенты нашей сети не могут к нему достучаться. Проидитесь по всем узлам и удалите из настроек данные адреса на координаторе или клиентах

[AnTonN(c)]

Схема полутуннеля или полный туннель?

[Sanya]

полутуннель

[AnTonN(c)]

Клиент при обращении на туннель не знает, что трафик надо шифровать. Этот трафик приходит на координатор. Координатор видит, что этот трафик для туннеля от клиента, и ожидает, что он будет зашифрованный.

Проверьте настройки на клиенте в части туннелей и их адресов видимости.

[Sanya]

ок поробую в настройка клиента туннелированные адреса должны быть строчки ip адрес 10.0.0.1 192.168.0.1 и в цусе S:10.0.0.1 S:192.168.0.1

[slavanchuk]

Настройки клиента другой сети вообще трогать не нужно - ни про какие туннели он знать не может. Главное, чтобы при этом не было конфликта по виртуальным адресам. То есть, лучше стартовый адрес на клиенте поменять. Более того, проще было бы сделать межсетевое взаимодействие. Если говорить о туннеле, то координатор лишь в том случае должен ждать от определённого адреса защищённый трафик, если этот адрес прописан у него за одним из связанных абоненстких пунктов. Какая-нибудь связь между клиентом чужой сети и вашей сетью есть? В ЦУСЕ на координаторе нужно прописывать только реальный адрес данного клиента, чтобы он мог его транслировать. Также у клиента должны быть прописаны маршруты на виртуальную подсеть вашей сети или координатор должен быть для него шлюзом.

[Sanya]

картина организации сети такая что бы вы понимали. есть координатор на нем 3 интерфейса wan который смотрит на меж сет экран 2Й интефейс основная сети оргонизации. 3 Й интерфейс сегмент обмена. основной интерфейс lan 10.0.0.1 реальный адрес сети. 10.0.0.2 server домена 10.0.0.5 клиент випнет нашей сети. сегмент обмена 192.168.0.1 адрес клиента на котором стоит випнет другой сети 192.168.0.2 нужно что бы компьютеры видели друг друга по сети. клиент другой сети обновился до версии 3,2 у нас так и остались клиенты 3,1 может сдесь есче может быть загвостка .Межсетевое взаимодействие есть с другой сетью.

[slavanchuk]

Судя по тому, что вы написали, у Вас вообще не туннель. У Вас просто не идёт трафик от клиента чужой сети до клиентов Вашей сети (если я правильно понял). Тогда это вообще не из разряда туннелирования и никакие туннели прописывать не нужно. Нужно только иметь связи с данным клиентом по типу коллектива и чтобы на стороне другой сети был обработан экспорт и высланы обновления. В этом случае у Вас должна быть связь также между координатором и клиентом внешней сети. Координатор для клиента будет сетевым экраном (это должно быть у него в настройках). И клиенты будут иметь доступ к данному внешнему клиенту через координатор. То, что Вы прописываете туннели на компьютере, где стоит vipnet - это октрытый трафик, который соответственно блокируется.

Хотя, по тексту не очень пойму. Вы туннелируете адрес 192.168.0.1. А говорите про ошибку 22 на координаторе. Эта ошибка всё-таки при попытке клиента внешней сети куда-то обратиться? Не могли бы Вы пояснить куда от кого нужен доступ и где по какой причине блокируется. Схему сети я Вашу понял.

[Sanya]

не много не так все клиенты находяться у нас разница между ними в том что один федеральный и региональные и деляться на подсети. 192.168.0.2 Клиент федеральный но он находиться в нашей сети 192,168.0.1 стоит в настройках ip шлюзом. на координаторе интефейс 3. 10.0.0.5 клиент нашей сети шлюз стоит 10.0.0.1 интерфейс координатора 2 . при ping от 10,0,0,5 до 192,168,0,2 на итерфейсе 10.0.0.1 в журнале координатора стоит 22- незашифровоный пакет от сетевого узла и так же ping 192.168.0.2 до 10.0.0.5 на интерфейсе 192.168.0.1 в журнале координатора стоит 22- не защифрованный пакет от сетевого узла . туннелирование .(1 )10,0,0,1-10,0,0,254 (2) клиент федеральный соответственно ip 192.168.0.2

10.0.0.1 192.168.0.1 транзитные фильтры.

[slavanchuk]

Так, получается никакие транзитные фильтры и туннели настраивать не нужно - у Вас просто соединение клиент-клиент. Вопрос в другом - почему не шифруется трафик при отправке на координатор. Связь между клиентами по ТК точно есть? И записи "S:10.0.0.1 S:192.168.0.1" нужно убрать. Вы, кстати, из какого ведомства? А то знакомая схема работы.

[AnTonN(c)]

При такой схеме клиенты будут видеть друг друга по умолчанию под виртуальными адресами. Обращение надо вести на них. Вообще f5 есть?

[Sanya]

да клиенты видят друг друга по f5 но только через випнет а нужно что бы по сети видели в сетевом окружении . вот и танцы с бубном по сетки они не доступны . эта схема работала . глюки пошли после смены белого ip и обновления федерального клиента до версии 3,2 .

[slavanchuk]

Вообще, общие папки можно открыть через Vipnet Client монитор по виртуальному адресу. Всё-таки не подскажете из какой Вы отрасли/министерства?