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

Рекомендуемые сообщения

Доброго времени суток.

Очередная проблема:(

Пропала связь клиента с координатором, хотя вроде как шифрованные пакеты доходят до координатора.

Привожу скрины журнала пакетов на координаторе, настройки блока [id] для данного клиента (ClientAP5) в файле iplir.conf.

Первые 2 скрина - исходящие пакеты от ClientAP5, третий скрин - входящие к клиенту. В списке входящих пакетов отображаются отображаются пакеты двух типов: crypto и forward.

Для пакетов типа crypto пишет ошибку Key Not Found For ID:

b503d197bcf5.jpg

Для пакетов типа forward пишет ошибку Unknown Destination Address, хотя на клиенте и в MFTP прописаны настройки координатора (до сегодняшнего дня абсолютно с теми же настройками работало норм):

2dfdbfcb4c49.jpg

Входящие пакеты (пинговал с координатора, пинг не проходил):

e809be356aa3.jpg

Ну и еще настройки клиента в файле iplir.conf:

4bdd3baa4da2.jpg

Если что нужно дополнительно, до завтрашнего вечера (16-00 по мск) смогу предоставить. Я уже не представляю, где может быть собака зарыта..

Ссылка на комментарий
Поделиться на других сайтах

Во-первых, ошибка про ключи однозначно говорит, что Вам необходимо пробросить (хоть на флешке, если связи нет) ключи (не обновления ключей, а ключевые наборы).

Во-вторых, ошибка связанная с IP-адресом говорит, что на координаторе неизвестны адреса клиента/координатора из сторонней сети. Лучше, если они были прописаны в справочниках. Если нет, то пропишите на координаторе их вручную.

Ссылка на комментарий
Поделиться на других сайтах

Во-первых, ошибка про ключи однозначно говорит, что Вам необходимо пробросить (хоть на флешке, если связи нет) ключи (не обновления ключей, а ключевые наборы).

Во-вторых, ошибка связанная с IP-адресом говорит, что на координаторе неизвестны адреса клиента/координатора из сторонней сети. Лучше, если они были прописаны в справочниках. Если нет, то пропишите на координаторе их вручную.

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

А вот с первой проблемой так и не получилось справиться. Я создал новый дистрибутив (по идее он уже содержит актуальные ключевые наборы) и на флешке перенес его на АП, который не может связаться с координатором, произвел первичную инициализацию. Ситуация не изменилась

Ссылка на комментарий
Поделиться на других сайтах

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

А вот с первой проблемой так и не получилось справиться. Я создал новый дистрибутив (по идее он уже содержит актуальные ключевые наборы) и на флешке перенес его на АП, который не может связаться с координатором, произвел первичную инициализацию. Ситуация не изменилась

Кроме того, в ЦУСе добавил в связи ТК "проблемного" АП еще один АП уже из своей сети (назовем Клиент1), соответственно отправил обновления на добавленный АП, а на "проблемный" сформировал новый дистрибутив.

Теперь ситуация такая: "проблемный" по-прежнему не видит клиентов из сторонней сети и координаторы (свой и из сторонней сети), но зато видит Клиента1 из своей сети. Клиент1 также видит "проблемный" АП.

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

Настройки для данного клиента в iplir.conf:

[id]

id= 0x0570000f

name= ClientAP5

filterdefault= pass

ip= 172.20.47.225

accessip= 172.20.47.225

firewallip= 91.202.255.68

port= 55777

proxyid= 0x0570000a

dynamic_timeout= 0

usefirewall= on

virtualip= 10.0.0.6

version= 3.0-671

Ссылка на комментарий
Поделиться на других сайтах

А клиент1 или любой другой клиент видит внешние узлы? Межсетевой ключ введён в эксплуатацию? На координаторе обновления ключей проходят (см. журнал запросов и ответов)?

Ссылка на комментарий
Поделиться на других сайтах

Только "проблемный" клиент связан с внешними пользователями. На координаторе обновления ключей проходят нормально, также как и на прочих АП.

Насчет межсетевого ключа. Недавно истек срок действия закрытого ключа администратора, создал новый корневой сертификат, разослал обновления своим клиентам. Связь со сторонней сетью поддерживалась, но с одним условием: у нас писало, что их почта была подписана недействительным сертификатом и наоборот, у них писало, что наши подписи недействительны. От сторонней сети приходит периодически в ЦУС импорт, т.е. опять же координатор норм отрабатывает.

Но даже если что-то с сетевыми ключами, разве "проблемный" клиент координатор видеть не должен?

Ссылка на комментарий
Поделиться на других сайтах

Пролистал тему ещё раз. Получается,что проблема с ключами у нас при попытке доступа к своему координатору, а проблема с ip-адресом при работе с внешним координатором. Всё-таки убедитесь, что у Вас для узла 0x01D0007C прописан accessip (это должно решить первую проблему). А проблема с ключами, насколько я понимаю, решилась переинициализацией. Но он всё равно не увидит сторонние узлы, пока мы не пропишем маршрут координатору (ведь, судя по настройкам, он работает через координатор).

Ссылка на комментарий
Поделиться на других сайтах

Узел 0x01D0007C находится в сторонней сети. Для этой сети прописаны только настройки ее координатора (раньше было то же самое, клиенты разных сетей обменивались сообщениями).

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

Ссылка на комментарий
Поделиться на других сайтах

Узел 0x01D0007C находится в сторонней сети. Для этой сети прописаны только настройки ее координатора (раньше было то же самое, клиенты разных сетей обменивались сообщениями).

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

Хорошо, теперь по поводу проблемы с ключами. После переинициализации "проблемный" клиент видит только клиента из той же подсети, с которым он может связаться и без участия координатора. Непосредственно с координатором связи нет, я об этом выше писал. Т.е. проблема осталась.

По-прежнему ошибка "key not found for id"

Ссылка на комментарий
Поделиться на других сайтах

Хорошо, теперь по поводу проблемы с ключами. После переинициализации "проблемный" клиент видит только клиента из той же подсети, с которым он может связаться и без участия координатора. Непосредственно с координатором связи нет, я об этом выше писал. Т.е. проблема осталась.

По-прежнему ошибка "key not found for id"

Проблема key not found пишется на координаторе, значит не у клиента не было ключей для связи с координатором, а наоборот. То есть, провести первичную инициализацию стоит на координаторе. Или, как минимум, отправить полный ключевой набор, а не обновление ключей. Простое обновление не высылает все ключи.

Ссылка на комментарий
Поделиться на других сайтах

Проблема key not found пишется на координаторе, значит не у клиента не было ключей для связи с координатором, а наоборот. То есть, провести первичную инициализацию стоит на координаторе. Или, как минимум, отправить полный ключевой набор, а не обновление ключей. Простое обновление не высылает все ключи.

Все гениальное - просто. Спасибо огромное за помощь.

Ссылка на комментарий
Поделиться на других сайтах

Гость
Эта тема закрыта для публикации сообщений.
×
×
  • Создать...

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

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