Vipnet coordinator для чего нужен
Виртуализированный криптошлюз ViPNet Coordinator VA. Инструкция по применению
Виртуализированный криптошлюз ViPNet Coordinator VA. Инструкция по применениюСпикер: Дмитрий Ипатов, специалист техподдержки компании «ИнфоТеКС»
Мы решили обобщить вопросы, связанные с виртуализированным криптографическим шлюзом ViPNet Coordinator VA версии 4.5.1 (далее координатор), которые часто получают сотрудники нашей техподдержки. В этой статье мы рассмотрим наиболее распространенные схемы внедрения, научимся пользоваться первичными средствами диагностики прохождения трафика, увидим с помощью tcpdump, как устанавливается защищенное соединение, с точки зрения сетевого оборудования.
Оговоримся сразу, не важно, насколько вы опытны в настройке и использовании СКЗИ, однако наличие базовых понятий о сетях ViPNet (практический опыт по созданию топологии защищенной сети, файлов первичной инициализации DST, установке и настройке координаторов) очень желательны.
С основной терминологией, используемой в данной статье, вы можете ознакомиться в глоссарии, размещенном в конце данной статьи.
Для подключения координатора к внешней сети предусмотрено четыре режима работы:
В текущем документе все настройки производятся через командный интерпретатор, так называемую командную строку, имеющую свой особый синтаксис. С помощью командного интерпретатора можно получить доступ ко всем настройкам координатора. Рассмотрим подробнее режимы подключения.
Режим «Со статической трансляцией адресов»
Схема 1. Режим «Со статической трансляцией адресов»
На схеме 1 указаны координаторы, которые располагаются за МЭ, находящимися на границах сетей.
Замечу, что сами координаторы также могут выполнять роль сертифицированного МЭ, но об этом речь пойдет в отдельной статье, а в данной рассмотрим только вопросы организации шифрованного канала.
В данной схеме на одной стороне находится координатор с именем ViPNet Coordinator 1, а с другой — ViPNet Coordinator 2. Между координаторами мы разместим вымышленную сеть, имитирующую Интернет с ip-адресами из диапазона 4.4.4.0/24.
ViPNet Coordinator 1 использует внешний адрес 172.0.0.2, а ViPNet Coordinator 2 — 172.0.1.2.
Для дальнейшего расширения сети у ViPNet Coordinator 1 будет настроена внутренняя сеть в диапазоне 192.168.0.0/24, а у ViPNet Coordinator 2 в диапазоне 192.168.1.0/24.
Чтобы облегчить последующую настройку и введение оборудования в «живую» сеть рекомендуется большинство известных параметров сразу задавать в управляющем приложении: ViPNet Administrator Центр управления Сетью (ЦУС).
Указываем тип используемого МЭ в выпадающем меню «Со статической трансляцией адреса» и ip-адрес доступа к ViPNet Coordinator 1 через МЭ на вкладке настроек МЭ:
На вкладке «адреса во внешних сетях» указываем все адреса, которые будут настроены на сетевых интерфейсах ViPNet Coordinator 1:
Очень важно добиться от администратора МЭ 1 и 2 корректной настройки именно статической трансляции адреса по указанному в ЦУС порту (по умолчанию это протокол udp и порт 55777).
Актуальные версии координаторов поддерживают также установку шифрованного канала по протоколу tcp, однако только между координатором и клиентами (ViPNet Client). Если данный тип подключения актуален для вас, то его также потребуется указать в ЦУС и настроить на МЭ правило статической трансляции указанного порта. Но на текущий момент работа между координаторами возможна только по протоколу udp.
Сформировав и развернув файл первичной инициализации (dst) на координаторе, мы получим конфигурационный файл iplir следующего вида:
Самой первой всегда идет секция собственных настроек. Каждая секция начинается со строки «[id]», далее следуют идентификатор и имя узла, а затем строки с ip-адресами сетевых интерфейсов координатора, которые мы задавали в ЦУС. Их уже настроили в процессе первичной инициализации координатора, они начинаются с «ip=». Сами строки при запуске iplir (командой iplir start) будут считаны из сетевой подсистемы координатора, т.е. будут отображены только те ip-адреса, которые физически на координаторе присутствуют.
Строка «tunnel» показывает какие ip-адреса туннелирует координатор.
Строка «firewallip» определяет ip-адрес доступа к координатору из внешних сетей. До установки соединений с другими узлами этот адрес берется из справочников, которые были сформированы нами в ЦУС, а после начала работы этот адрес определяется по ответным пакетам от других узлов сети, т.е. может меняться.
«Port» также берется из справочников ЦУС и может быть изменен вручную или автоматически, в определенных сценариях, речь о которых пойдет ниже. Особенностью драйвера iplir является то, что принимать шифрованные пакеты он будет на любом порту, даже отличном от 55777, а отправлять будет всегда с того порта, который указан в данной строке.
«Proxyid» параметр также участвует в определении режима работы узла, при работе в режиме «Со статической трансляцией адресов» должен быть установлен в нулевое значение.
«Usefirewall» принимает значения «on», тогда МЭ используется, если «off» — без МЭ.
«Fixfirewall» как правило в «on» включать не следует, так как этот параметр передается на другие узлы и будет предписывать им отправлять ответные пакеты исключительно на тот адрес, который указан в строке «firewallip», что может привести к частичной или полной недоступности координатора. Использование данного параметра уместно в крайне ограниченном количестве сценариев, когда вы точно уверены в том, что делаете.
«Tcptunnelport» если между координатором и клиентом (пока координаторы между собой умеют работать только по udp) невозможно соединиться по udp-протоколу, то клиент будет пробовать установить соединение по tcp. Функционал обычно востребован при пребывании в аэропорту или, отеле, т.е. в тех местах, где жесткие правила пограничных МЭ могут обеспечивать пропуск только tcp-трафика как правило на порты 80 (http) и 443(https).
«Version» указывает на внутреннюю версию драйвера iplir, версию прошивки можно определить, запустив команду version в командном интерпретаторе.
Таким образом, уже после просмотра только собственной секции координатора мы можем определить, какие параметры он использует: используется МЭ (статика или динамика узнаем совсем скоро), у него два сетевых интерфейса с ip-адресами 172.0.0.2 и 192.168.0.1, а удаленные узлы будут получать к нему доступ по адресу 4.4.4.1. Причем, так как все эти настройки мы задали в ЦУС, то в составе справочников они попадут на другие узлы и нам не нужно будет указывать на них параметры доступа вручную.
Теперь идем в самый низ конфигурационного файла, в секцию [dynamic]:
Тут нас интересует строка «dynamic_proxy», если там «off», то в сочетании «usefirewall» и «proxyid» из собственной секции установлен режим «со статической трансляцией адреса», если «dynamic_proxy»=on, то режим «с динамической».
Параметры ViPNet Coordinator 1 понятны, теперь аналогично проанализируем параметры ViPNet Coordinator 2, для этого нужно найти секцию с его идентификатором и именем:
Строки «id» и «name» уже были рассмотрены ранее, это идентификатор координатора и его имя, заданное в ЦУС, строки, начинающиеся с «ip=» тоже раньше встречались, однако отображение для собственной секции координатора и секция других узлов существенно различаются, в дополнение отображаются не только те реальные адреса, которые мы задали в ЦУС, но и после запятой присвоенные им виртуальные адреса, с которыми мы еще не были ранее знакомы.
Следом идет очень важная строка «accessip», которая определяет адрес, по которому наш координатор будет обращаться к удаленному. Такая строка, а, следовательно, и адрес могут быть только в единственном числе! В ней может быть указан или виртуальный адрес, или один из реальных ip-адресов, физически настроенных на удаленном координаторе.
В нашем примере мы будем работать со всеми узлами только по реальным адресам. Для управления параметром видимости удаленного узла, которая заставит использовать только реальный адрес, необходимо внести изменения в конфигурационный файл iplir:
iplir stop
iplir config
затем найти секцию узла, в которую вносятся изменения, и добавить туда следующую строчку «visibility=real». После чего выйти из конфигурационного файла с сохранением «ctrl + x и y», далее применяем настройки «iplir start».
Теперь секция ViPNet Coordinator 2 должна выглядеть следующим образом:
«Tunnel», «firewallip», «port» и «version» были описаны ранее, однако добавились следующие параметры:
«Accessiplist» — определяет IP-адреса доступа к узлу и их приоритет.
«Proxyid» тут имеет несколько иное значение, чем тот же параметр в собственной секции.
0хfffffffe для режимов «Со статической трансляцией адресов» (наш случай) или «С динамической трансляцией адресов» в случае, если координатор является еще и сервером ip-адресов, ноль для режима «без МЭ» и 16-ричный идентификатор для режимов «Координатор» или «С динамической трансляцией адресов».
«dynamic_timeout» — период опроса (в секундах) ViPNet-координатора, выбранного в качестве межсетевого экрана для данного узла (актуален только для режима «С динамической трансляцией адресов»), чтобы периодическими опросами поддерживать правило пропуска трафика на МЭ, за которым находится координатор.
«Virtualip» — виртуальный адрес, присвоенный узлу.
«Tunnel_local_networs» позволяет вручную отключить туннелирование адресов, входящие в локальную подсеть координатора.
Итого на удаленном узле используется режим работы «Со статической трансляцией адресов», адрес доступа к координатору реальный 172.0.1.2, адрес МЭ 4.4.4.2.
И в том и в другом случае на удаленный узел пойдет зашифрованный трафик, однако при iplir ping будут отправлены тестовые пакеты на все адреса, указанные в строках «accessiplist», «ip» и «firewallip» по протоколу udp и порту 2046, которые на выходе будут зашифрованы драйвером iplir и инкапсулированы в udp с портом, указанным в строке «port» конфигурационного файла, а параметр «accessip» примет значение в зависимости от того, с какого адреса первым придет ответ. В случае получения ответного пакета будет выведено сообщение, что связь с удаленным узлом установлена, если ответов нет или они пришли, но были заблокированы по какой-либо причине драйвером iplir, будет выведено сообщение о таймауте соединения. Важной особенностью выполнения данной команды является то, что ответ может прийти только с защищенного узла, идентификатор которого мы указали в команде.
При inet ping никакого перебора не будет, пакеты сразу направляются согласно таблице маршрутизации координатора на указанный адрес, затем драйвер инкапсулирует этот пакет в udp и направляет на firewallip удаленного узла. Зато пакеты будут идти до тех пор, пока пользователь не выполнит прерывание данной команды. Результаты выполнения будут сразу же видны на экране, аналогично стандартной утилите ping. Следует отметить, что если при iplir ping мы гарантированно получим ответ только от защищенного узла, то по inet ping нам может ответить любой узел с ip-адресом, указанным в запущенной команде. Так, если видимость удаленного узла сменилась на виртуальную, то пакет с нашего координатора может уйти нешифрованным, так как решение о необходимости его шифрования принимает драйвер iplir на основании загруженных в него адресов доступа защищенных узлов. Таким образом необходимо визуально контролировать, что параметр «accessip» в секции удаленного узла не принял иного значения перед выполнением данной команды.
Кроме отображения непосредственно на экране пакеты также регистрируются в специальных файлах: журналах ip-пакетов. Журналы ведутся по каждому интерфейсу в отдельном файле и их параметры могут быть отредактированы. По умолчанию в журналах регистрируются только заблокированные пакеты, отключить эту настройку невозможно, однако можно включить регистрацию пропущенных пакетов и увеличить сам размер журнала, что позволит хранить в нем информацию за больший временной промежуток. По достижении максимального размера журнала самые старые записи будут удаляться из него.
Включим регистрацию пропущенных пакетов на двух задействованных в нашей схеме сетевых интерфейсах координатора, для этого снова нужно остановить iplir: iplir stop.
Редактируем конфигурационный файл интерфейса eth0: iplir config eth0.
В строке registerall меняем «off» на «on» и выходим с сохранением: «ctrl + x и y».
Аналогичные действия производим для интерфейса eth1.
Запускаем iplir: iplir start.
Теперь на интерфейсах eth0 и eth1 в журналах будут регистрироваться все прошедшие через него пакеты до тех пор, пока размер журнала не достигнет 50 Мбайт.
Запустим для начала iplir ping и дождемся результатов его выполнения на экране:
Связь установлена, теперь посмотрим, как это отображается в журнале.
Вызвать графическое приложение для просмотра журнала ip-пакетов можно командой iplir view:
Тут присутствует большое количество выборок, можно отсортировать журнал по интерфейсу, протоколу, ip-адресу, идентификатору узла и пр. Так как в нашей тестовой сети всего два узла, то пользоваться сортировкой мы пока не будем, а сразу перейдем к поиску «find»:
Красные строчки — заблокированные пакеты, зеленые — пропущенные. Та строка, на которой установлен курсор, ярко зеленая.
Расшифровка колонки «flags» следующая:
> — входящий пакет;
C — шифрованный пакет;
B — широковещательный пакет;
D — заблокированный пакет;
T — транзитный пакет;
R — пакет, который будет обработан правилами NAT открытой сети;
N — пакет, который был обработан правилами NAT открытой сети.
В журнале отображаются пакеты из прикладной подсистемы, отправленные до шифрования драйвером, а принятые пакеты уже после расшифровки, поэтому журнал показывает адреса «accessip» и порты, на которые отправляются пакеты именно прикладными системами координатора.
Между двумя красными строчками с заблокированными пакетами видны шифрованные пакеты от 172.0.0.2 на 172.0.1.2 и получены шифрованные ответы на них, udp 2046 как раз проверка связи по команде iplir ping.
Теперь проверим доступность координатора с использованием inet ping.
Предварительно проверим значение «accessip» у ViPNet Coordinator 2 в iplir show config.
Текущий адрес доступа к узлу 172.0.1.2, запускаем на него inet ping.
Визуально пинг идет, проверим журнал ip-пакетов.
Видим отправленные и принятые пакеты по протоколу icmp с 172.0.0.2 на 172.0.1.2.
Опять журнал нам показывает информацию до того момента, как исходный пакет будет инкапсулирован в udp и отправлен далее по сети.
В нашем случае мы видим успешную установку соединения по iplir ping и прохождение пакетов по inet ping, т.е удаленный узел доступен.
Остановимся подробнее на схеме доставки трафика: ViPNet Coordinator 1 при обращении к ViPNet Coordinator 2 будет использовать параметр «accessip» и передавать пакеты в сетевой стек с данным адресом назначения. На выходе драйвер iplir определит по accessip, к какому координатору происходит обращение, зашифрует трафик, заменив в заголовке пакета адрес назначения на firewallip секции удаленного координатора, а в адресе источника будет адрес сетевого интерфейса, с которого уйдет трафик согласно таблице маршрутизации координатора.
В нашем случае в таблице маршрутизации, кроме connected сетей, только один маршрут по умолчанию через МЭ 1: 172.0.0.1, поэтому пакет пойдет сразу на него.
Запустим inet ping 172.0.1.2 и установим снифер трафика между ViPNet Coordinator 1 и МЭ 1:
Видно, что с адреса ViPNet Coordinator 1 172.0.0.2 уходят пакеты по udp 55777 на firewallip ViPNet Coordinator 2: 4.4.4.2.
Теперь снимем трафик после МЭ 1.
После МЭ произошла трансляция адреса источника (NAT) чтобы в интернет не попал «серый» адрес ViPNet Coordinator 1, на который мы бы не получили ответных пакетов. Со стороны кажется, что узлы с адресами 4.4.4.1 и 4.4.4.2 просто обмениваются трафиком по udp 55777.
После МЭ 2 трафик выглядит так:
Т.е. МЭ 2 осуществил статическую трансляцию адреса и перенаправил трафик, пришедший на адрес 4.4.4.2, на адрес ViPNet Coordinator 2 172.0.1.2.
Теперь от ViPNet Coordinator 2 вся цепочка преобразований будет выполнена уже в обратном порядке пока трафик не достигнет ViPNet Coordinator 1.
Первый сценарий успешно реализован, переходим к более сложной схеме.
Режим «С динамической трансляцией адресов»
Рассмотрим еще одну популярную схему, где перед ViPNet Coordinator 1 все также расположен МЭ, осуществляющий статическую трансляцию адреса, а перед ViPNet Coordinator 2 расположен МЭ, осуществляющий динамическую трансляцию адреса, что, кстати, в реальных сетях бывает довольно часто.
При использовании данной схемы необходимо, чтобы на МЭ со статической трансляцией адреса был настроен фиксированный маршрутизируемый ip-адрес, так как если этот адрес будет изменяться в процессе работы, то удаленные узлы потеряют соединение с ViPNet Coordinator 1 и восстановить его будет крайне сложно.
Основная идея заключается в том, что на стороне ViPNet Сoordinator 2, расположенного за МЭ 2, используется специальный режим работы, при котором периодически (по умолчанию раз в 25 секунд) посылаются тестовые запросы на ip-адрес «firewallip» ViPNet Coordinator 1. Данные запросы позволяют поддерживать активной сессию на МЭ 2, так как при отсутствии в ней активности подавляющее большинство подобного оборудования ее закроют в течении довольно короткого времени (обычно от 1 до 5 минут).
ViPNet Coordinator 1 выступает в данном сценарии как «Сервер соединений» для ViPNet Coordinator 2 и будет устанавливать соединения между клиентами и координаторами по кратчайшему пути, если они находятся в разных подсетях и не могут соединиться друг с другом напрямую.
Если же сессию не поддерживать, и она закроется, то со стороны ViPNet Coordinator 1 установить инициативное соединение с ViPNet Coordinator 2 будет невозможно.
Также данный режим имеет возможность следующей настройки: либо направлять весь защищенный трафик через свой сервер соединений, либо с удаленным узлом устанавливается прямое соединение или соединение через его сервер соединений, если настройка отправки трафика не установлена.
Настроим в ЦУС тип МЭ для ViPNet Coordinator 2.
При выборе МЭ «С динамической трансляцией адреса» можно дополнительно указать через какой сетевой интерфейс координатора будет доступен данный МЭ, заполнить сами ip-адреса МЭ (что бывает довольно редко, ведь как минимум внешний адрес динамически изменяется) и в обязательном порядке нужно выбрать координатор для организации соединений с внешними узлами. Именно на него будут отправляться тестовые пакеты с периодом опроса, который указывается в настройках и обычно не требует изменения.
После разворачивания dst на ViPNet Coordinator 2 его конфигурационный файл примет следующий вид: «proxyid» в собственной секции принял значение «0xfffffffe».
В секции «[dynamic]» параметр «dynamic_proxy» стал «on», т.е. специальный режим включился, в качестве координатора, для организации соединений прописался идентификатор ViPNet Coordinator 1. Давайте теперь убедимся, что специальный режим функционирует корректно, для этого не будем передавать никакого полезного трафика между координаторами, а просто включим прослушивание трафика между МЭ 1 и МЭ 2 на несколько минут:
C адреса 4.4.4.2 каждые 25 секунд посылается пакет на адрес 4.4.4.1, что позволяет держать открытым соединение на МЭ 2. В остальном взаимодействие между координаторами ничем не будет отличаться от предыдущей схемы с режимом «статическая трансляция адреса» на обоих координаторах.
Стоит отметить, что в нашей простейшей схеме, где минимум узлов, при осуществлении динамической трансляции адреса на МЭ 2 даже не изменяется порт источника, а остается изначальный 55777, если же за МЭ будет большое количество узлов, для которых необходимо осуществлять NAT, то вместо 55777 мы можем получить любой порт из диапазона 1024-65535, что однако не будет являться проблемой, на стороне ViPNet Coordinator 1 этот порт зафиксируется в соответствующем параметре и в дальнейшем ответные пакеты будут направляться именно на него.
Режим «Координатор»
Данный режим использовался в устаревших версиях программного обеспечения и в настоящее время оставлен только для обеспечения совместимости с ними. В ближайшее время он будет исключен из числа поддерживаемых.
Вместо этого режима лучше использовать Режим «с динамической трансляцией адресов» и передачей всего трафика через сервер соединений, имеющий меньше ограничений.
Таким образом для каскадных схем, в которых число координаторов в цепочке передачи трафика более двух рекомендуется использовать либо режим «со статической трансляций адреса», если между координаторами нет устройств, осуществляющих динамический NAT или режим «с динамической трансляцией адресов» с направлением всего защищенного трафика через сервер соединений, если устройства с динамическим NAT присутствуют.
Режим «Без использования межсетевого экрана»
Аналогичная ситуация и с данным режимом, его присутствие обусловлено вопросами совместимости с предыдущими версиями и время, когда он исчезнет из числа поддерживаемых, неумолимо приближается.
Вместо него производителем предлагается все тот же универсальный режим «со статической трансляций адреса».
Заключение
Надеемся, данная статья окажется для вас полезной. Попробовать реализовать все вышеописанное вы можете сами, скачав образ виртуальной машины и два уже сформированный dst файла. Скачать демо-версию
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-ой линии администрирования «Ростелеком-Солар»