Криптошлюз что это такое
Криптошлюз
Содержание
Назначение
Криптошлюз предназначен для обеспечения информационной безопасности организации, защиты её информационных сетей от вторжения со стороны сетей передачи данных (Интернет), обеспечения конфиденциальности при передаче информации по открытым каналам связи (VPN), а также организации безопасного доступа пользователей к ресурсам сетей общего пользования.
Криптошлюз обеспечивает базовую функциональность современного VPN-устройства:
Криптошлюзы представлены как в сегменте VPN устройств, так и в сегменте унифицированных устройств (UTM) объединяющих несколько средств безопасности в одном.
Доступ к ресурсам информационной системы
Криптошлюзы позволяют осуществить защищенный доступ удаленных абонентов к ресурсам корпоративной информационной системы. Доступ производится с использованием специального программного обеспечения, установленным на компьютере пользователя (VPN-клиент) для осуществления защищенного взаимодействия удаленных и мобильных пользователей с криптошлюзом.
Программное обеспечение криптошлюза (сервер доступа) проводит идентификацию и аутентификацию пользователя и осуществляет его связь с ресурсами защищаемой сети. С помощью криптошлюзов формируют виртуальные защищенные каналы в сетях общего пользования (например, Internet), которые гарантируют конфиденциальность и достоверность информации, и организовывать виртуальные частные сети (Virtual Private Network – VPN), представляющие собой объединение локальных сетей или отдельных компьютеров, подключенных к сети общего пользования в единую защищенную виртуальную сеть. Для управления такой сетью обычно используется специальное программное обеспечение (центр управления), которое обеспечивает централизованное управление локальными политиками безопасности VPN-клиентов и криптошлюзов, рассылает для них ключевую информацию и новые конфигурационные данные, обеспечивает ведение системных журналов.
Опыт внедрения криптошлюзов ViPNet в ЕРИС
Коротко о ЕРИС
ЕРИС (Единый Радиологический Информационный Сервис) представляет собой информационную систему, объединяющую высокотехнологичную медицинскую технику, рабочие места рентгенологов и единый архив диагностических изображений. В настоящее время ЕРИС объединяет магнитно-резонансные, цифровые аппараты классического рентгена, аппараты для проведения флюорографии и компьютерные томографы в 64 поликлиниках города Москвы, включая амбулаторные учреждения Зеленограда.
Основные задачи ЕРИС — повысить эффективность лучевой диагностики в Москве, создать единую сеть, объединяющую диагностическую аппаратуру, обеспечить современную и надежную систему хранения получаемых в результате исследований изображений, описаний и заключений.
Необходимость применения криптошлюзов
Так как в информационной системе ЕРИС обрабатываются персональные данные пациентов, то необходимо выполнять требования ФЗ-152 «О персональных данных» и подзаконных актов, связанных с этим законом. Одним из требований по защите персональных данных является организация защищенных каналов связи с помощью средств криптографической защиты информации (СКЗИ). В соответствии с этим требованием мы приступили к проектированию системы защиты персональных данных в целом и СКЗИ в частности.
Критерии выбора, схема тестирования, пилот, финальный выбор
Нашей компании Элефус Заказчик в лице компании Лаваль выдвинул ряд требований, которым должны были соответствовать СКЗИ, среди них основные:
Схема тестирования была следующая:
Рисунок 1 — Схема тестирования
В ходе тестирования передавались снимки трех типов: КТ, ММГ, ПЭТКТ (они отличаются размерами файлов, частотой взаимодействия клиент-сервер), различные варианты снимков позволили смоделировать различные типы нагрузок на криптошлюзы. Замеры задержек и скорость в канале производились программами WinMTR и iperf3.
По результатам тестирования Континент и ViPNet оказались в лидерах, их результаты были сопоставимы, КриптоПро отставал незначительно, а МагПро сильно влиял как на скорость, так и на задержки в канале.
Дальше после взаимодействия с вендорами Заказчиком было принято финальное решение в пользу ViPNet. Оставим финальный выбор за скобками данной статьи, с технической точки зрения Континент и ViPNet практически одинаковые.
ИнфоТеКС (производитель ViPNet) предоставил для пилотного тестирования следующее оборудование:
Как внедряли? Схема, сложности, преднастройка
К внедрению нам необходимо было подойти с особой тщательностью. Как я говорил выше, медицинские работники радиологических кабинетов постоянно загружены, поэтому на внедрение СКЗИ на объекте нам отводилось 15 минут. Внедрение мы проводили совместно с инженерами Лаваль, которые хорошо знали местное оборудование.
Внедрение состояло из следующих этапов:
Мониторинг. Нагрузка на процессор, оперативную память, сеть
Дальше мы покажем скриншоты из системы мониторинга, где можно посмотреть нагрузки на оборудование отдельно за полгода и отдельно за один рабочий день (ЦП, ОЗУ, сеть). Названия сетевых устройств скрыты, с точки зрения смысловой нагрузки это ни на что не влияет.
Нагрузка на ЦП
Рисунок 2 — Загрузка ЦП за полгода HW1000
Рисунок 3 — Загрузка ЦП за 1 день HW1000
Рисунок 4 — Загрузка ЦП за полгода HW50
Рисунок 5 — Загрузка ЦП за 1 день HW50
Нагрузка на оперативную память
Рисунок 6 — Загрузка ОЗУ за полгода HW1000
Рисунок 7 — Загрузка ОЗУ за 1 день HW1000
Рисунок 8 — Загрузка ОЗУ за полгода HW50
Рисунок 9 — Загрузка ОЗУ за 1день HW50
Нагрузки на сеть
Рисунок 10 — Загрузка сеть за полгода HW1000
Рисунок 11 — Загрузка сеть за 1 день HW1000
Рисунок 12 — Загрузка сеть за полгода HW50
Рисунок 13 — Загрузка сеть за 1 день HW50
Криптошлюз что это такое
Обзоры российского рынка криптошлюзов
В статье кратко описываются тенденции мирового рынка VPN, рассматриваются популярные криптошлюзы, представленные на российском рынке, приводятся их ключевые особенности.
Введение
Криптографический шлюз (криптошлюз, криптомаршрутизатор, VPN-шлюз) — программно-аппаратный комплекс для криптографической защиты трафика, передаваемого по каналам связи, путем шифрования пакетов по различным протоколам.
Криптошлюз предназначен для обеспечения информационной безопасности организации при передаче данных по открытым каналам связи.
Криптошлюзы, представленные на современном рынке, обеспечивают следующие базовые функции:
Предприятия различного масштаба, государственные учреждения, частные компании — основные категории потребителей криптошлюзов.
На сегодняшний день функциональность VPN-шлюза является составной частью практически любого сетевого устройства, будь то маршрутизатор корпоративного уровня, домашний Wi-Fi-роутер или межсетевой экран. С учетом данной специфики ниже будут рассмотрены ключевые представители российского рынка, использующие алгоритм шифрования ГОСТ, а также несколько зарубежных примеров в качестве альтернативы.
Отдельной строкой отметим присутствие на рынке решений для защищенного удаленного доступа на базе протокола TLS (TLS-шлюзы) как российских, так и иностранных производителей. В рамках этого обзора они не рассматриваются.
Мировой рынок криптошлюзов
Непрерывность бизнеса для любой территориально распределенной компании всегда связана с обеспечением защиты передаваемой информации. Уже долгое время эту задачу решают различные VPN-устройства.
Они заметно отличаются по своей реализации: это могут быть специализированные решения, решения на базе программно-аппаратных комплексов, таких как межсетевые экраны/маршрутизаторы, или полностью программные комплексы.
Подобные продукты на мировом рынке применяют компании из разных сфер деятельности: здравоохранение, промышленные предприятия, транспортные компании, государственные учреждения и многие другие.
В большинстве случаев заказчику необходимо решить одну или несколько из перечисленных задач:
На мировом рынке прочно обосновался SSL VPN, что подтверждается исследованиями Alliedmarketresearch. По их данным, глобальный рынок SSL VPN в 2016 году составлял более 3 млрд долларов США. Прогнозируемый рост к 2023 году — до 5,3 млрд.
Среди ключевых игроков на мировом рынке лидерские позиции занимают Cisco Systems, Citrix Systems, Pulse Secure, F5 Networks.
Рисунок 1 наглядно демонстрирует ключевые сегменты роста глобального рынка SSL VPN:
Рисунок 1. Направления роста мирового рынка SSL VPN
Российский рынок криптошлюзов
В России основными потребителями криптошлюзов являются государственные учреждения, а также организации, являющиеся операторами персональных данных. На территории нашей страны действуют несколько нормативных актов, определяющих критерии, по которым средства защиты информации могут использоваться для решения тех или иных задач.
К таким документам можно отнести следующие:
Апкш «континент» — ipc-25
| Форм-фактор | Mini-ITX, высота 1U |
| Габариты (ВхШxГ) | 155 х 275 x 45 мм |
| Процессор | Intel Atom C2358 частотой 1743 МГц |
| Оперативная память | SODIMM DDR3 DRAM, 2 Гбайта, PC-1333 |
| Сетевые интерфейсы | 4х 1000BASE-T Ethernet 10/100/1000 RJ45 (выполнены в виде легко заменяемых модулей) |
| Жесткие диски | SATA DOM модуль 4Gb |
| Блок питания | внешний адаптер переменного тока 19В, 220B 80Вт |
| Считыватель | Touch Memory |
| Персональные идентификаторы | Touch Memory iButton DS1992L 2шт. |
| Встроенный модуль АПМДЗ | ПАК «Соболь» 3.0 (mini-PCIe) |
| USB-flash drive | не менее 512 Мб |
| Уровень акустического шума при 100% загрузке (методика измерения ISO7779) | 37 dBA |
| Встроенная операционная система | Continent OS – усовершенствованная ОС с усиленной безопасностью на основе ядра FreeBSD |
В состав АПКШ «Континент» 3.7 входит:
Сертификаты
Интерфейс управления криптошлюзом Ideco МагПро
Внимание! Поставка данного продукта временно приостановлена. Новая версия криптографического ПО будет доступна позже.
Всем пользователям Ideco ICS доступна возможность применения Программно-аппаратного комплекса «Ideco МагПро ГОСТ-VPN» на базе сертифицированного СКЗИ «МагПро КриптоПакет» для построения безопасных каналов связи между филиалами корпоративной сети и передачи персональных данных.
Решение функционирует на уровне отдельного программно-аппаратного устройства «Ideco МагПро ГОСТ-VPN», выполненного на базе СКЗИ «МагПро КриптоПакет», которое работает под управлением операционной системы Debian.
Настройка «Ideco МагПро ГОСТ-VPN» может быть в полной мере осуществлена через веб-интерфейс Ideco ICS, что позволяет внедрить решение в кратчайшие сроки и с минимальными усилиями.
Программно-аппаратный комплекс «Ideco МагПро ГОСТ-VPN» это комплект из двух и более программно-аппаратных устройств, которые могут администрироваться через интерфейс интернет-шлюза Ideco ICS.
Преимущества Ideco МагПро
Условия поставки
В комплект поставки входят:
Интерфейс управления криптошлюзами Ideco МагПро ГОСТ-VPN доступен пользователям версии Ideco ICS 5.3 и старше.
Поставка программных продуктов для криптографической защиты соединения в комплектации, установленной нормативными требованиями, выполняется со стороны производителя СКЗИ – компанией «Криптоком».
На уровне Интернет-шлюза Ideco ICS встраивания криптографического ПО и криптографических вычислений не происходит. Все программные компоненты СКЗИ «МагПро КриптоПакет» базируются на отдельном аппаратном сервере, под управлением собственной встроенной ОС.
| Лицензия А1(до 30 Мбит/сек) | Atom D510/1Gb/GigEth |
| Лицензия А3(до 60 Мбит/сек) | Intel Celeron Dual-Core E3400 2.60/SATA 250GB/1Gb/GigEth/DVD/mATX |
| Лицензия А9(до 90 Мбит/сек) | Intel G860 Dual-core 3.00GHz,3MB/SATA 250Gb/4Gb/2xGigEth/DVD |
Стоимость
Итоговая стоимость зависит от количества соединяемых офисов (минимум 2) и скорости передачи данных.
Сценарии применения
Необходимость применения сертифицированных средств криптографической защиты возникает в следующих случаях:
Архитектура
В головном офисе программно-аппаратный комплекс Ideco МагПро ГОСТ-VPN подключается к выделенному сетевому интерфейсу интернет-шлюза Ideco ICS и настраивается в режиме сервера.
В дочерних подразделениях комплекс настраивается в режиме клиента. Между сервером и клиентами создаются VPN-туннели, по которым передается трафик, зашифрованный с применением криптографических алгоритмов, соответствующих ГОСТ.
Скриншоты
Купить Договор-оферта Документация
Криптографические шлюзы (VPN)
Криптографические шлюзы (криптошлюзы, VPN) — это программно-аппаратные или программные комплексы, реализующие технологию VPN, обеспечивающие «прозрачное» шифрование сетевых информационных потоков между территориально удалёнными объектами. Применение криптошлюзов необходимо в тех случаях, когда требуется обеспечить конфиденциальность и целостность данных, передаваемых по незащищённым или недоверенным каналам связи.
VPN (виртуальные частные сети) могут быть организованы по принципу «сеть — сеть» или «сеть – удаленный пользователь». При реализации принципа «сеть — сеть» криптошлюзы устанавливаются с обеих сторон канала связи — в точках подключения локальной сети объекта к оператору связи, и трафик между ними шифруется.
Существует множество технологий и схем организации защищённых сетей. Среди наиболее известных топологий: средства криптографической защиты класса Hub-and-Spoke — каждый филиал соединяется с центром, и Full Mesh — каждый объект соединяется с каждым. У различных производителей существует множество собственных технологий и вариантов реализации VPN.
С точки зрения используемых протоколов можно выделить несколько типов VPN:
Основные функции криптошлюзов
Зачастую криптографические шлюзы одновременно выполняют функции межсетевых экранов. Однако далеко не всегда гибкость, полнота функций и другие параметры криптошлюзов могут сравниться с аналогичными характеристиками специализированных межсетевых экранов.
Законодательные требования
Результат применения решения
Предлагаемые решения
Компания «Микротест» предлагает профессиональные услуги по консалтингу, выбору оптимального решения, проектированию, внедрению следующих криптографических шлюзов:
SecRating
Криптографические шлюзы (криптошлюзы, VPN) — это программно-аппаратные или программные комплексы, реализующие технологию VPN, обеспечивающие «прозрачное» шифрование сетевых информационных потоков между территориально удалёнными объектами. Применение криптошлюзов необходимо в тех случаях, когда требуется обеспечить конфиденциальность и целостность данных, передаваемых по незащищённым или недоверенным каналам связи.
VPN (виртуальные частные сети) могут быть организованы по принципу «сеть — сеть» или «сеть — удаленный пользователь». При реализации принципа «сеть — сеть» криптошлюзы устанавливаются с обеих сторон канала связи — в точках подключения локальной сети объекта к оператору связи, и трафик между ними шифруется.
Существует множество технологий и схем организации защищённых сетей. Среди наиболее известных топологий: Hub-and-Spoke — каждый филиал соединяется с центром, и Full Mesh — каждый объект соединяется с каждым. У различных производителей существует множество собственных технологий и вариантов реализации VPN.
С точки зрения используемых протоколов можно выделить несколько типов VPN:
Результат применения решения
Предлагаемые решения
Компания «Микротест» предлагает профессиональные услуги по консалтингу, выбору оптимального решения, проектированию, внедрению следующих криптографических шлюзов:
ViPNet в деталях: разбираемся с особенностями криптошлюза
Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ. 
В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.
Координатор недоступен
«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.
Конверт не доставлен
Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу). Значит, если вы захотите отправить письмо по деловой почте, то клиент упакует его в конверт и отправит сначала на свой координатор. Далее на пути могут быть еще несколько координаторов, и только после этого конверт попадет на узел адресата.
Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.
Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.
Последствия перепрошивки
Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI. Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. Например, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.
Неинформативные конфиги
Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».
Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.
(Un)split tunneling
Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»). Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.
Служебные порты и TCP-туннель
Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.
Замена координатора
Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.
Кластеризация и сбой ноды
Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.
При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.
В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.
Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.
Пересечения адресов
В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.
Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.
Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.
Невозможность работы GRE
Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:
Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).
Не забываем про время
Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.
Нешифрованный трафик вместо зашифрованного
Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:
Обработка прикладных протоколов (ALG)
На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:
В заключение
Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.
Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»