Проблемы В Настройке Vipnet Client В Режиме Работы Через Маршрутизатор

[balancev]

Здравствуйте! У меня развернута сеть VipNet следующего состава:

1. Координатор tbserver (IP: 10.10.1.3), находится в локальной сети главного офиса организации, поключен к Internet через маршрутизатор Dlink DIR-320 со статическим NAT. Адрес маршрутизатора во внешней сети 62.192.239.65. На маршрутизаторе настроено правило переадресации портов. Порт 55777 переадресован на 10.10.1.3.

2. В сети другого офиса установлен VipNet Client. Сеть также отделена от Internet маршрутизатором DIR-320. У маршрутизатора переадресация портов не включена. Более того, внешний адрес маршрутизатора относится к частной сети провайдера. На VipNet Client установлен режим работы через маршрутизатор с динамической трансляцией адресов.

При попытке проверить соединение с координатором выводится сообщение "Координатор не доступен". Но если я подключаю компьютер с VipNet Client напрямую к Internet (отсоединяю витую пару от DIR-320 и подключаю к компьютеру), и меняю режим работы клиента на "Не использовать межсетевой экран", все начинает работать нормально и координатор становится доступен. В чем может быть проблема?

[Stratos]

При попытке проверить соединение с координатором выводится сообщение "Координатор не доступен". Но если я подключаю компьютер с VipNet Client напрямую к Internet (отсоединяю витую пару от DIR-320 и подключаю к компьютеру), и меняю режим работы клиента на "Не использовать межсетевой экран", все начинает работать нормально и координатор становится доступен. В чем может быть проблема?

По моему ответ очевиден - проблема в настройке маршрутизатора...

[balancev]

Не очень понятно. Поменял маршрутизатор, проверил, результат тот же. Насколько я понял, при работе в режиме "Динамический NAT" VipNet Client в состоянии работать практически через любое устройство. Может быть, я что-то не так сделал в iplir.conf? Какие настройки проверять у маршрутизатора для того, чтобы заработал VipNet-клиент?

[balancev]

Продолжу тему. Проблема не решилась, я просмотрел журнал регистрации IP-пакетов на координаторе. При подключении АП через NAT пакеты отвергаются, причина 1-Key not found for id:

Time begin | Time end | Dev| Eth | Flags|Prot| Source IP | Port| Destination IP| Port| Size | Cnt|SourceAP|DestinAP| Event

07.05.2011 12:31:19|07.05.2011 12:31:44|eth0| 800h|>DC---| udp| 172.29.192.63|55777| 10.10.1.3|55777| 256| 2|0602000E|0602000A|1 - Key not found for ID

То есть, до координатора пакеты доходят, но им отвергаются.

[balancev]

Внезапно все стало хорошо... В чем причина, понятия не имею.

[Echo]

Внезапно все стало хорошо... В чем причина, понятия не имею.

Ключа не было, теперь - есть...

Возможно, обновление на Координатор было не выслано, или выслано, но не применилось, а теперь время подошло

[balancev]

Проблемы продолжились.

1. Добавил новые АП в ЦУС, установил необходимые связи в конфигурации.

2. Передал справочники в УКЦ.

3. Сгенерировал ключи для АП и пользователей и дистрибутивы ключей.

4. Передал ключи обратно в ЦУС, из ЦУС разослал по СУ.

5. Установил с полученного дистрибутива новый АП.

Результат: ранее установленный АП "видит" координатор и новые АП, если новые АП находятся физически в той же подсети (не за маршрутизатором).

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

На координаторе попытка обмена данными с новыми АП приводит к появлению сообщения в логе "Key not found for ID". При этом от того, находится новый АП за маршрутизатором или в той же подсети, результат никак не меняется.

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

В чем может быть проблема? Что я должен проверить, чтобы убедиться, что координатор получил/установил нужные ключи?

Клиент версии 3.1, координатор под управлением Linux.

[balancev]

Чудеса, опять само прошло. Стоит только написать кляузу на форуме, как координатор принимается за ум и начинает работать как надо... Вчера вечером с ключами полтора часа мучался, сегодня с утра все заработало. Откуда такая выдержка времени?

[Stratos]

balancev

мистика

[balancev]

История со странным поведением координатора получила продолжение. Добавил два новых АП, симптомы те же - новые АП не взаимодействуют с координатором.

1. Сначала отправлял ключевые наборы через ЦУС.

2. Не достигнув успеха, на следующий день сгенерировал новый дистрибутив для координатора, перенес его вручную.

3. Когда и это не помогло, повторно сгенерировал ключевые наборы и отправил через ЦУС.

Прошло ещё два дня - новые АП могут работать со старыми АП в пределах одной подсети, но координатор отвергает все пакеты от них с сообщением "Key not found for ID".

Стаые АП работают с координатором нормально.

Как мне проверить, получил ли координатор ключи для новых АП? Что предпринять, чтобы понять причину проблемы?

Проблема №2 с координатором - после неожиданной перезагрузки (например, в результате отключения питания) он перестает принимать пакеты от всех компьютеров, хотя iplir работает. Перезапуск iplir (iplir stop -> iplir start) не помогает, но помогает повторная перезагрузка компьютера. До установки координатора никаких проблем с перезагрузками никогда не случалось. В чем может быть дело?

[Stratos]

balancev

По проблеме 1:

сдается мне, у Вас по всей сети "разьехались" справочно-ключевая информация.

Выходов несколько - снимать журналы IP пакетов с узлов сети, анализировать, снимать журналы MFTP со всех узлов сети - анализировать. Смотреть что где разьехалось и восставноить соответствие. Либо переинициализировать все узлы сети новыми DST.

По проблеме 2:

Какая версия Координатора? Возможно, проблема не в ViPNet, а в самом оборудовании. Например в драйвере сетевой карты.

[balancev]

Посмотрел упомянутые логи. Связь с ЦУС устойчива, проблем вроде-бы нет. В логе MFTP связь с ЦУС описана серией записей такого вида:

[11-23 13:13:49] CheckUpdateResults: No '*.up' files found.

[11-23 13:17:00] CMftpConnection.Accept: Accepted connection from 10.10.1.4:1336 (fd 22).

[11-23 13:17:00] Init: FD 22 <- "INF V=3.53 I=0602000B A=1 C=0 R=060200010001 7=29EA451ED0181C50"

[11-23 13:17:00] FormINF8Data: FD 22: Use fixed key

[11-23 13:17:00] Init: FD 22 -> "INF V=3.53 I=0602000A A=1 C=0 R=060200010000 8=3EB7F20AE614428A9D453162FC5B1548"

[11-23 13:17:00] Init: FD 22 <- "AUT 9=36F71A78A91F94E9"

[11-23 13:17:00] Init: FD 22 -> "AUT 0"

[11-23 13:17:00] ProcessMftpConnection: Init MFTP connection successful on Sock 22.

[11-23 13:17:01] ExchangeRecv: FD 22 <- "GET"

[11-23 13:17:01] ExchangeRecv: FD 22 -> "GET"

[11-23 13:17:31] ProcessMftpConnection: Wait timeout expired. Sock 22.

[11-23 13:17:31] CMftpConnection.Close: Close connection. Sock 22.

В папке "in", похоже, скопились все мои отправленные ключи, там 98 файлов .CTL

Для того, чтобы переинициализировать координатор, достаточно выполнить команду unmerge? Или требуются ещё какие-то действия?