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

Coordinator Linux: Нет Свзязи Между Защищенными Узлами В


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

Коллеги, помогите советом, что мы могли неправильно настроить?

Имеем четыре сервера на Linux c установленными на них VipNet Coordinator Linux. Два находятся в одной физической сети, два - в другой, сети общаются друг с другом через интернет, на границах сети - шлюзы, тоже на Linux+VipNet Coordinator. В ЦУС настроены связи (вроде бы нормально, по инструкции), шлюзы настроены, NAT работает, незащищенные компьютеры имеют доступ в интернет, и даже могут обращаться друг к другу из разных сетей, если указать для них туннелирование (в качестве теста). Но между собой серверы в разных сетях общаться не могут. И если пытаться туннелировать незащищенные комьютеры из одной сети с целью дать им доступ к защищенному узлу в другой сети - тоже не получается. Если кратко, то работает только связь незащищенных компьютеров в разных сетях через туннелирование на шлюзах, а а связь между защищенными серверами в разных сетях и туннелирование незащищенных компьютеров одной сети к защищенному серверу в другой - нет. Где мы могли ошибиться?

Заранее спасибо.

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

Коллеги, помогите советом, что мы могли неправильно настроить?

Имеем четыре сервера на Linux c установленными на них VipNet Coordinator Linux. Два находятся в одной физической сети, два - в другой, сети общаются друг с другом через интернет, на границах сети - шлюзы, тоже на Linux+VipNet Coordinator. В ЦУС настроены связи (вроде бы нормально, по инструкции), шлюзы настроены, NAT работает, незащищенные компьютеры имеют доступ в интернет, и даже могут обращаться друг к другу из разных сетей, если указать для них туннелирование (в качестве теста). Но между собой серверы в разных сетях общаться не могут. И если пытаться туннелировать незащищенные комьютеры из одной сети с целью дать им доступ к защищенному узлу в другой сети - тоже не получается. Если кратко, то работает только связь незащищенных компьютеров в разных сетях через туннелирование на шлюзах, а а связь между защищенными серверами в разных сетях и туннелирование незащищенных компьютеров одной сети к защищенному серверу в другой - нет. Где мы могли ошибиться?

Заранее спасибо.

Немного непонятно. Схема была бы уместнее. Во-первых, что такое "защищённый" и "назащищённый" компьютеры? Защищённый - это компьютер с VIpNet Client/Coordinator или с каким-то СЗИ от НСД? 6 Ваших координаторов принадлежат одной сети VipNet или нескольким?

Предположим, что у Вас на защищённых серверах стоит координатор. В этом случае вы должны обращаться к нему по адресу accessip, указанному для данного сервера на координаторе, за которым стоит туннелируемый узел. Не факт, что это будет реальный адрес сервера. VipNet, скорее всего, ему сгенерировал другой адрес. Скорее всего, затык у Вас в этом.

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

Во-первых, что такое "защищённый" и "назащищённый" компьютеры? Защищённый - это компьютер с VIpNet Client/Coordinator или с каким-то СЗИ от НСД? 6 Ваших координаторов принадлежат одной сети VipNet или нескольким?

Защищенные - это защищенные VipNet Coordinator Linux, других средств нет. Они принадлежат одной сети.

Предположим, что у Вас на защищённых серверах стоит координатор. В этом случае вы должны обращаться к нему по адресу accessip, указанному для данного сервера на координаторе, за которым стоит туннелируемый узел. Не факт, что это будет реальный адрес сервера. VipNet, скорее всего, ему сгенерировал другой адрес. Скорее всего, затык у Вас в этом.

Спасибо за ответ. Я постараюсь заново переинициализировать шлюзы и проследить за адресами accessip.

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

Защищенные - это защищенные VipNet Coordinator Linux, других средств нет. Они принадлежат одной сети.

Спасибо за ответ. Я постараюсь заново переинициализировать шлюзы и проследить за адресами accessip.

Не обязательно переинициализировать. Можно попробовать их просто задать. Вроде бы, редактировать эти поля допустимо (хотя, по документации не рекомендуется). В случае в HW1000 эти поля могут вовсе отсутствовать (реальный случай из жизни), но их можно добавить.

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

Уважаемый slavanchuk, спасибо вам за подсказку! Нам удалось точнее отдиагностировать происходящее, хотя проблема пока не решилась. Полагаю, мы все-таки что-то неправильно настроили в ЦУСе. Сейчас могу сказать, что ситуация выглядит так: с каждого из шлюзов доступна его внутренняя сеть по реальным адресам (что логично) и защищенные сетевые узлы в сети за другим шлюзом по виртуальным айпи. Но при этом защищенные серверы, находящиеся в разных сетях, друг друга по-прежнему не видят. Даже по виртуальным адресам. Каков необходимый минимум настроек ЦУС для обеспечения связи защищенных узлов, находящихся в разных сетях, между собой? Может быть, мы с туннельными лицензиями что-то намудрили?

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

Уважаемый slavanchuk, спасибо вам за подсказку! Нам удалось точнее отдиагностировать происходящее, хотя проблема пока не решилась. Полагаю, мы все-таки что-то неправильно настроили в ЦУСе. Сейчас могу сказать, что ситуация выглядит так: с каждого из шлюзов доступна его внутренняя сеть по реальным адресам (что логично) и защищенные сетевые узлы в сети за другим шлюзом по виртуальным айпи. Но при этом защищенные серверы, находящиеся в разных сетях, друг друга по-прежнему не видят. Даже по виртуальным адресам. Каков необходимый минимум настроек ЦУС для обеспечения связи защищенных узлов, находящихся в разных сетях, между собой? Может быть, мы с туннельными лицензиями что-то намудрили?

С туннелями ситуация простая. Если у Вас хватает лицензий на туннели, то необходимо просто в ЦУСе рапределить эти туннельные лицензии по координаторам - и всё. Для связи достаточно также добавить в справочники адреса туннелируемых узлов. Это - необходимый минимум. В остальном могут быть проблемы в маршрутизации - нужно смотреть журналы (что куда уходит). Если у Вас координаторы работают как шлюзы, то проблем теоретически быть не должно (если маршрутизация между координаторами нормально работает). Совет один - смотреть журналы.

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

Все же не получается. И непонятно в чем проблема.

С туннелями ситуация простая. Если у Вас хватает лицензий на туннели, то необходимо просто в ЦУСе рапределить эти туннельные лицензии по координаторам - и всё.

Но ведь для связи самих защищенных узлов туннельная лицензия не требуется (такой вывод я сделал из постов на форуме)?

Для связи достаточно также добавить в справочники адреса туннелируемых узлов. Это - необходимый минимум.

Опять же, это касается только незащищенных туннелируемых узлов, верно? У нас их не так много, основная проблема в свободном хождении пакетов между защищенными VipNet Coordinator серверами в двух сетях, разделенных интернетом.

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

Мне начинает казаться, что проблема именно в маршрутизации. Но тут у меня затык - из вдумчивого чтения документации я сделал вывод, что координаторы на пограничных узлах должны самостоятельно заниматься NATом для зашифрованных пакетов. Я делаю такой тест: беру два координатора, находящихся в локальных сетях за координаторами, выполняющими функции шлюзов. Перевожу их в режим "Координатор", то есть указываю, что они должны общаться через координаторы, установленные на шлюзах. На самих шлюзах координаторы работают в режиме "без межсетевого экрана". Пробую установить связь между серверами, находящимися за шлюзами... И тишина. Связи нет, в iplir view не видно по этому поводу ровным счетом ничего.

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

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

Все же не получается. И непонятно в чем проблема.

Но ведь для связи самих защищенных узлов туннельная лицензия не требуется (такой вывод я сделал из постов на форуме)?

Опять же, это касается только незащищенных туннелируемых узлов, верно? У нас их не так много, основная проблема в свободном хождении пакетов между защищенными VipNet Coordinator серверами в двух сетях, разделенных интернетом.

Мне начинает казаться, что проблема именно в маршрутизации. Но тут у меня затык - из вдумчивого чтения документации я сделал вывод, что координаторы на пограничных узлах должны самостоятельно заниматься NATом для зашифрованных пакетов. Я делаю такой тест: беру два координатора, находящихся в локальных сетях за координаторами, выполняющими функции шлюзов. Перевожу их в режим "Координатор", то есть указываю, что они должны общаться через координаторы, установленные на шлюзах. На самих шлюзах координаторы работают в режиме "без межсетевого экрана". Пробую установить связь между серверами, находящимися за шлюзами... И тишина. Связи нет, в iplir view не видно по этому поводу ровным счетом ничего.

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

Для связи туннельных узлов друг с другом никакие лицензии дополнительные не нужны. По одной лицензии - на каждый незащищённый АП - вполне достаточно. У Вас незащищённые АП стоят за шлюзовыми координаторами или за серверами? Лучше бы им быть за шлюзовыми координаторами. Каскадное включение тут не стоит использовать. А в случае с координаторами-серверами настроили Вы всё верно. У Вас же на одном из сетевых интерфейсов шлюзовых координторов внешний белый адрес записан? Сами-то шлюзовые координаторы друг друга видят? Я, так понимаю, у Вас затык именно в связи серверов-координаторов за шлюзовыми координаторами? А туннели нормально работают?

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

У Вас же на одном из сетевых интерфейсов шлюзовых координторов внешний белый адрес записан? Сами-то шлюзовые координаторы друг друга видят? Я, так понимаю, у Вас затык именно в связи серверов-координаторов за шлюзовыми координаторами? А туннели нормально работают?

Все именно так. Внешний адрес в настройках шлюзов указан. Шлюзовые координаторы между собой общаются. Если через шлюзовые координаторы туннелировать незащищенные ресурсы - туннели работают. А серверы-координаторы за шлюзовыми координаторами друг друга не видят.

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

Все именно так. Внешний адрес в настройках шлюзов указан. Шлюзовые координаторы между собой общаются. Если через шлюзовые координаторы туннелировать незащищенные ресурсы - туннели работают. А серверы-координаторы за шлюзовыми координаторами друг друга не видят.

Получается, что по настройкам всё верно - на координаторах за шлюзовым координатором должен быть "каскад", то есть "работать через коордиратор". У сервера-координатора в качестве шлюза по умолчанию (TCP/IP) в сети указан шлюзовой координатор? Судя по журналам, куда уходят пакеты? Стоит посмотреть журнал пакетов как на сервере-координаторе, так и на шлюзе, чтобы понять куда он их всё-таки отправляет. Настройки лучше рассылать через ЦУС (чтобы была гарантированная согласованность в настройках на координаторах) в части работы через межсетевой экран.

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

У сервера-координатора в качестве шлюза по умолчанию (TCP/IP) в сети указан шлюзовой координатор? Судя по журналам, куда уходят пакеты?

Да, у всех машин в обоих сетях dhcp раздает адреса соответствющих шлюзов в качестве default gateway. Впрочем, где статика - там тоже они вписаны.

С журналами очень странная ситуация. Если поднимаются шлюзы на vipnet и координаторы прописываются в каскад, то в iplir view я просто не вижу пакетов. Пингую серверы в удаленной сети по реальному ip, по виртуальному ip - и тишина, ответа нет, в журналах пусто, только в журнале debug вижу сообщения об отправке пакетов, и, затем, о достижении порога "timeout" (истечение времени ожидания ответа). Смотрю журналы на всей цепочке серверов: сначала на исходном, потом на пограничном шлюзе, потом на удаленном шлюзе, потом на сервере-адресате. И ничего не вижу.

Любопытная подробность: если между сетями поднять сторонний канал с маршрутизацией (например, openvpn), то внутри него защищенная сеть работает (пакеты начинают ходить между всеми серверами по виртуальным адресам).

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

Дополню: в качестве теста перебил на одном из шлюзов настройки сети и сделал его обычным защищенным координатором - в этой роли он отлично связывается с любыми другими защищенными узлами. Уточнил у провайдера, не блокируются ли какие-либо порты - ответ отрицательный.

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

Дополню: в качестве теста перебил на одном из шлюзов настройки сети и сделал его обычным защищенным координатором - в этой роли он отлично связывается с любыми другими защищенными узлами. Уточнил у провайдера, не блокируются ли какие-либо порты - ответ отрицательный.

Интересный случай. Порты тут однозначно не причём, так как порт используется всего один - UDP 55777 (если по умолчанию). Пробовали ставить на координаторе "со статической трансляцией"? Я не уверен, что в режиме "без экрана" он будет упаковывать пакеты в UDP (хотя, должен). А что значит обычный защищённый координатор?

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

Пробовали ставить на координаторе "со статической трансляцией"?

Пока нет, но спасибо за совет - надо попробовать.

А что значит обычный защищённый координатор?

Я имел в виду, что задействовал на будущем шлюзе только внутренний сетевой интерфейс, дал ему другой внутренний ip, поправил в iplir.conf настройки доступа к другим координаторам (получился такой же сервер, как и остальные сетевые узлы) и связь между ними нормально работает. Между сетями, как я уже писал, поднят канал ipsec с маршрутизацией локальных адресов, и через него защищенная связь по виртуальным ip работает без проблем, но нам хотелось бы избавиться от лишних машин и на пограничном устройстве задействовать только vipnet.

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

Пока нет, но спасибо за совет - надо попробовать.

Я имел в виду, что задействовал на будущем шлюзе только внутренний сетевой интерфейс, дал ему другой внутренний ip, поправил в iplir.conf настройки доступа к другим координаторам (получился такой же сервер, как и остальные сетевые узлы) и связь между ними нормально работает. Между сетями, как я уже писал, поднят канал ipsec с маршрутизацией локальных адресов, и через него защищенная связь по виртуальным ip работает без проблем, но нам хотелось бы избавиться от лишних машин и на пограничном устройстве задействовать только vipnet.

В случае с VPN у вас получается, что координаторы доступны друг другу по broadcast и они используют упрощённый протокол для связи. В случае использования сети интернет, пакеты упаковываются в UDP. Видимо, происходит какая-то беда с маршрутизацией пакетов. Кстати, а как у Вас настроены межсерверные каналы? Подключен только один внешний канал (Интернет)?

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

В случае с VPN у вас получается, что координаторы доступны друг другу по broadcast и они используют упрощённый протокол для связи. В случае использования сети интернет, пакеты упаковываются в UDP. Видимо, происходит какая-то беда с маршрутизацией пакетов.

Мне тоже так кажется. Только непонятно, куда копать - разве что проверю еще раз взаимную доступность 55777 порта, чистоту правил iptables и для проверки перейду в режим "за статическим NAT". Не знаю, что еще можно придумать.

Кстати, а как у Вас настроены межсерверные каналы? Подключен только один внешний канал (Интернет)?

Нет, созданы каналы между всеми координаторами. Может быть, все-таки в ЦУСе что-то не доделано?

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

Мне тоже так кажется. Только непонятно, куда копать - разве что проверю еще раз взаимную доступность 55777 порта, чистоту правил iptables и для проверки перейду в режим "за статическим NAT". Не знаю, что еще можно придумать.

Нет, созданы каналы между всеми координаторами. Может быть, все-таки в ЦУСе что-то не доделано?

Вряд ли дело в настройках ЦУС. Все настройки сети (тип межсетевого экрана, адреса и прочее) лучше делать в ЦУСе, в справочниках, а не локально на координаторах. Также, вряд ли дело в доступности 55777, так как координаторы шлюзовые, как я понимаю, друг друга видят.

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

Присоединиться к обсуждению

Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.

Гость
Ответить в этой теме...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
×
  • Создать...

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

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