как узнать виртуальный ip адрес в vipnet
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-ой линии администрирования «Ростелеком-Солар»
Принципы маршрутизации и преобразования IP-трафика в VPN-сети, созданной с использованием технологии ViPNet
1. Введение
Технология ViPNet предназначена для создания защищенных виртуальных сетей (VPN) в глобальных и локальных IP-сетях. В отличие от других технологий VPN, технология ViPNet обеспечивает прозрачное взаимодействие защищаемых компьютеров, независимо от способа и места подключения этих компьютеров к сети, а также типа выделяемого адреса.
При этом обеспечивается не только гарантированная защита трафика, передаваемого между компьютерами, включенными в VPN, от перехвата и модификации, путем его шифрования, но также защита самих компьютеров от сетевых атак из любой точки сети за счет интегрированных в технологию ViPNet персональных и межсетевых экранов. Виртуальная сеть строится путем установки на компьютеры (сетевые узлы) двух типов программного обеспечения: ViPNet-клиента и ViPNet-координатора. ViPNet-клиент обеспечивает сетевую защиту и включение в VPN отдельных компьютеров. Компьютер с ViPNet-координатором обычно устанавливается на границах локальных сетей и их сегментов, обеспечивает включение в VPN открытых и защищенных компьютеров, находящихся в этих локальных сетях или их сегментах независимо от типа адреса, выделяемого им, разделение и защиту сетей от сетевых атак, а также оповещение ViPNet-клиента о состоянии других сетевых узлов, связанных с ним.
Пакет программ ViPNet реализован для операционных систем Windows, Linux, Solaris.
Управление виртуальной сетью, допустимыми связями и распределением ключевой информации между узлами обеспечивается из Центра управления сетью (ЦУС).
В настоящей статье рассматриваются основные принципы маршрутизации и преобразования трафика, реализованные в виртуальной сети ViPNet, обеспечивающие возможность безопасного взаимодействия компьютеров при любых способах их подключения к сети.
Принципы управления сетью, ее ключевая структура, принципы служебного взаимодействия узлов, осуществляемого на прикладном уровне, технология фильтрации трафика, прикладные системы и почтовый транспорт технологии ViPNet, технология создания инфраструктуры электронной цифровой подписи не являются предметом рассмотрения настоящей статьи.
2. Общие принципы взаимодействия узлов в виртуальной сети
Сетевые узлы (абонентские пункты и координаторы) сети ViPNet могут работать в глобальной сети как автономно, то есть не устанавливаться ни за какие типы межсетевых экранов (Firewall), так и могут устанавливаться за различные типы Firewall и другие устройства, выполняющие функции преобразования адресов (NAT). Выбор того или иного режима работы модуля ViPNet определяется местом и способом подключения узла ViPNet к сети.
Оповещение абонентского пункта о состоянии других узлов сети для взаимодействия с ними осуществляет сервер IP-адресов (функциональная составляющая координатора). По умолчанию функции сервера IP-адресов для абонентского пункта выполняет координатор, на котором этот абонентский пункт был зарегистрирован в ЦУСе. Этот координатор всегда владеет полным объемом информации обо всех узлах сети, связанных с данным абонентским пунктом. Однако пользователь, при необходимости, может выбрать в качестве сервера IP-адресов и любой другой координатор, доступный ему. В этом случае абонентский пункт также сможет получить информацию о большинстве связанных с ним узлов и рассказать им о себе. Команда о назначении сервера IP-адресов может быть прислана также из ЦУСа. Технология обмена информацией о сетевых настройках узлов в сети ViPNet выполняется на прикладном уровне операционной системы, но здесь подробно не рассматривается.
Все основные технические решения, обеспечивающие создание туннельных VPN-соединений и фильтрацию трафика, реализованы в низкоуровневом драйвере модуля ViPNet. Этот драйвер взаимодействует с драйверами сетевых интерфейсов (реальных или их эмулирующих) операционной системы и для него нет принципиального значения, каким способом подключен компьютер к сети. Это может быть сеть Ethernet или PPPoE через XDSL-подключение, PPP через обычный Dial UP или ISDN, сеть сотовой связи GPRS или Wireless-устройства, сети MPLS или VLAN. Модуль ViPNet автоматически поддерживает разнообразные протоколы канального уровня. Для создания туннельных VPN-соединений между узлами используется два типа IP-протокола, в который упаковывается любой другой IP-протокол: IP/241 и IP/UDP (с портом 55777 по умолчанию.)
При взаимодействии абонентских пунктов, доступных друг другу напрямую по реальному адресу узла (т.е. когда между ними отсутствуют устройства с NAT), система автоматически использует более экономичный протокол IP/241 (не имеющий дополнительных UDP-заголовков размером 12 байт). Этот же протокол используется при взаимодействии любых узлов, находящихся в одной локальной сети и принимающих друг от друга широковещательные пакеты,
При взаимодействии узлов, недоступных друг другу напрямую по реальному адресу узла (т.е. между ними есть устройства, выполняющие NAT, в том числе координаторы), система автоматически использует протокол UDP, для которого легко обеспечивается прохождение IP-пакетов через любые типы Firewall и другие устройства с NAT.
Для обеспечения возможности работы сетевых узлов из любых точек сети, модуль ViPNet имеет четыре основных режима работы через Firewal:
a) Автономная работа (без установки за Firewall c NAT),
b) Работа узла, установленного за ViPNet-координатор (тип Firewall «ViPNet-координатор»),
c) Работа узла, установленного за Firewall c NAT, на котором возможна настройка статических правил NAT (тип Firewall «Со статическим NAT»),
d) Работа узла, установленного за Firewall c NAT, на котором настройка статических правил NAT затруднительна или невозможна (тип Firewall «С динамическим NAT»).
Принцип выбора режима работы для конкретного сетевого узла вытекает из особенностей реализации в системе ViPNet технологии оповещения и авторегистрации состояния узлов и их местонахождения в сети, заключающихся в следующем:
Если узел имеет IP-адрес, доступный по общим правилам маршрутизации пакетов в IP-сети со стороны любых других узлов, с которыми этот узел должен взаимодействовать, например, имеет реальный адрес сети Интернет или корпоративной сети, то этому узлу достаточно сообщить другим узлам только свои IP-адреса. В этом случае может выбираться режим a).
Если узел имеет частный IP-адрес, по которому в соответствии с общими правилами маршрутизации нельзя получить доступ со стороны некоторых других узлов, т.е. при выходе во внешнюю сеть стоит Firewall или иное устройство, выполняющее преобразование адресов (NAT), то другие узлы должны узнать о данном узле существенно больше информации. Для бесперебойного доступа к данному узлу потребуется не только информация об адресах этого узла, но и информация об адресах и портах доступа в данный момент через устройство c NAT. В этом случае необходимо выбрать для данного узла один из режимов b), c), или d).
Следует также отметить, что если узлы находятся в одной локальной сети в области доступности друг другу по широковещательным пакетам, то независимо от выбранного режима работы взаимодействие между ними всегда осуществляется напрямую по IP-адресу узла.
Рассмотрим более подробно принципы работы сети ViPNet для каждого из этих режимов.
3. Работа узлов без использования Firewall
В этом случае опция «Использовать межсетевой экран (Firewall)» в настройках узла отключена. Такой режим следует использовать, если узел имеет хотя бы один IP-адрес, доступный напрямую с любого другого узла сети, связанного с данным узлом, например, реальный адрес Интернет. Любые узлы, установленные в этот режим, взаимодействуют между собой всегда напрямую по доступному адресу. При этом трафик между абонентскими пунктами в этом режиме инкапсулируется в IP-пакеты протокола IP/241 (Рисунок 3). Трафик таких узлов с координаторами, с узлами, находящимися за координаторами, другими типами Firewall, всегда упаковывается в протокол IP/UDP.
Если узел в таком режиме находится в локальной сети с частными адресами, подключенной к внешней сети через Firewall или другие устройства, осуществляющие преобразование адресов, то он не сможет взаимодействовать с узлами, находящимися во внешней сети.
ViPNet-координатор, находящийся в этом режиме и установленный на границе сетей, выполняет функции NAT для VPN-соединений между узлами ViPNet в сторону каждой из сетей. То есть во все IP-пакеты, инкапсулированные в UDP-формат и проходящие через ViPNet-координатор, в качестве адреса источника подставляется адрес соответствующего интерфейса координатора.
ViPNet-координатор выполняет также шифрование, инкапсуляцию в UDP-формат (туннелирование) заданного открытого трафика локальной сети, который должен быть передан другим узлам ViPNet или открытым компьютерам, находящимся за другими координаторами (Рисунок 3).
Туннелироваться может трафик любых устройств, находящихся со стороны любого сетевого интерфейса. При этом передача закрытого трафика производится от имени адреса интерфейса координатора, с которого уходит этот трафик, (то есть выполняется NAT).
Если узел ViPNet взаимодействует с туннелируемым некоторым координатором компьютером, и этот компьютер находится в одной подсети, заданной для узла ViPNet, то в этом случае узел ViPNet взаимодействует с этим компьютером напрямую без шифрования трафика.
Расшифрованные пакеты для туннелируемых компьютеров всегда отправляются в сеть от имени реального или виртуального (о технологии виртуальных адресов будет рассказано ниже) адреса компьютера, пославшего этот пакет.
4. Работа узлов с использованием типа Firewall «ViPNet-координатор
Если на границе локальной сети установлен ViPNet-координатор, то узлы, имеющие связь с ним, могут встать за этот координатор, то есть выбрать этот координатор в качестве узла, через который и от имени которого будет осуществляться обмен информацией между узлами, находящимися в разных сетях. В этом случае выбирается режим использования типа Firewall «ViPNet-координатор». По умолчанию в качестве Firewall всегда выбирается координатор (если иное не задано в ЦУСе), на котором данный абонентский пункт зарегистрирован в ЦУСе.
При необходимости в качестве такого Firewall пользователем (или по команде из ЦУСа) может быть выбран любой доступный данному узлу по прямому адресу координатор. Это дает возможность мобильным пользователям при приезде в другое место, где есть такой координатор, подключившись к локальной сети и получив там адрес, моментально получить доступ ко всем ресурсам, доступным из его собственной локальной сети. При этом в качестве сервера IP-адресов может оставаться его родной координатор, что позволяет одновременно получить полный объем информации для получения доступа к другим узлам, с которыми связан данный пользователь, поскольку чужой координатор может владеть такой информацией не в полном объеме. Команда о назначении другого координатора в качестве Firewall может быть прислана также из ЦУСа.
Возможность выбора для работы в качестве Firewall различных координаторов полезна, например, в случае выхода из строя отдельного оборудования или каналов связи.
Если узел установлен за координатор, то его трафик, предназначенный для других узлов, недоступных по широковещательным пакетам и:
Автоматическая маршрутизация зашифрованных пакетов на собственный координатор позволяет не устанавливать шлюз по умолчанию на свой координатор, и тем самым обеспечить возможность маршрутизации открытых пакетов, если это необходимо, на другие шлюзы, и не делать дополнительных настроек на компьютере после установки модуля ViPNet.
Технология ViPNet позволяет значительно упростить администрирование большой локальной сети, разделенной на сегменты различного рода маршрутизаторами и коммутаторами, на которых, как правило, в целях безопасности настраиваются допустимые для пропуска адреса и протоколы. Если узел такой сети установить за ViPNet-координатор, то не потребуется настройка множества допустимых внешних адресов и протоколов. В такой конфигурации будет циркулировать только UDP-трафик с внутренними адресами своего сегмента и внутренним адресом ViPNet-координатора.
Если в локальной сети, на границе которой установлен ViPNet-координатор, требуется обеспечить защиту трафика некоторого внутреннего сегмента сети в целом, то на границе этого сегмента сети может быть также установлен ViPNet-координатор, который устанавливается за внешний ViPNet-координатор (Рисунок 5).
То есть обеспечивается возможность каскадного включения координаторов с автоматической маршрутизацией трафика от внутреннего сегмента сети, как в локальную, так и внешнюю сеть.
5. Работа узлов с использованием типа Firewall «Со статическим NAT»
В ряде случаев на границе локальной сети может быть уже установлен Firewall другого производителя, выполняющий функции NAT, и в соответствии с политикой безопасности организации любой трафик во внешние сети должен проходить именно через этот Firewall, или просто нет возможности получить дополнительные внешние адреса. Любой узел ViPNet может быть установлен за этот Firewall. Если на этом Firewall доступна настройка статических правил NAT, о которых будет сказано ниже, то в этом случае выбирается режим c использованием типа Firewall «Со статическим NAT».
Если в локальной сети установлено несколько узлов ViPNet, то в такой ситуации наиболее удобно установить в этой сети также и ViPNet-координатор с одним или более сетевыми интерфейсами. На этом координаторе для одного из интерфейсов выбирается тип Firewall «Со статическим NAT». На компьютере с координатором настраивается маршрутизация на внешний Firewall (шлюз по умолчанию или маршруты для удаленных подсетей). Другие узлы ViPNet автоматически (если в ЦУСе не указано иное) по умолчанию установятся за этот координатор, (то есть станут в режим использования типа Firewall «ViPNet-координатор»). В этом случае пакеты от всех узлов на внешний Firewall будут попадать через координатор от имени его адреса. (Рисунок 6).
Если в локальной сети нет ViPNet-координатора, то на каждом из абонентских пунктов должен быть выбран тип Firewall «Со статическим NAT» и произведена настройка маршрутизации на внешний Firewall. При этом на каждом узле должен быть назначен свой порт доступа.
Для обеспечения свободного прохождения трафика через внешний Firewall на этом Firewall должны быть настроены статические правила NAT, обеспечивающие:
1. пропуск наружу UDP-пакетов с адресами и портами источников (с подменой адреса источника на свой адрес):
1а. если есть координатор, за который установлены все узлы, то только координатора (порт по умолчанию 55777, но его можно изменить),
2. перенаправление входящих пакетов на внутренние адреса, соответствующие порту назначения входящего пакета. Если есть общий координатор, то только на него (порт по умолчанию 55777). Если общего координатора нет, то в соответствии с портом назначения, заданного для каждого из узлов локальной сети.
6. Работа узлов с использованием типа Firewall «С динамическим NAT»
Такая ситуация типична для простых устройств NAT с минимумом настроек, используемых в частности в DSL-модемах, Wireless-устройствах, при использования технологии общего доступа Microsoft через компьютер, подключенный к Интернет по удаленному соединению. Затруднительно также произвести настройки на устройствах NAT, установленных у провайдера (в домовых сетях, GPRS и других сетях, где провайдер предоставляет частный IP-адрес).
Однако все устройства NAT обеспечивают пропуск UDP-трафика в режиме автоматического создания так называемых динамических правил NAT. То есть пропускаются любые исходящие пакеты с подменой адреса и порта, фиксируются их параметры (создаются динамические правила пропуска для входящего трафика), и в течение некоторого промежутка времени пропускаются входящие пакеты, параметры которых соответствуют созданным правилам. По истечении заданного промежутка времени после последнего исходящего пакета, соответствующие динамические правила удаляются, и входящие пакеты начинают блокироваться. То есть инициативное соединение извне с узлами, стоящими за такими устройствами NAT, невозможно, если не будет соответствующего исходящего трафика.
В окне настроек режима есть опция «Любой трафик с внешними узлами направлять через сервер IP-адресов», которая по умолчанию отключена. При ее включении весь исходящий и входящий трафик будет идти только через сервер IP-адресов, находящийся во внешней сети, что может существенно снизить скорость обмена. Поэтому включение этой опции рекомендуется только в специальных случаях, о которых будет сказано ниже. Если в локальной сети за устройством NAT есть несколько узлов ViPNet, то в такой ситуации наиболее удобно установить также ViPNet-координатор с одним или более сетевыми интерфейсами. На этом координаторе:
Другие узлы ViPNet автоматически по умолчанию (если иное не задано в ЦУСе) установятся за этот координатор, (то есть станут в режим использования типа Firewall «ViPNet-координатор»).
Если в локальной сети нет ViPNet-координатора, то на каждом из абонентских пунктов должен быть выбран тип Firewall «С динамическим NAT» и произведена настройка маршрутизации на внешнее устройство с NAT.
7. Специальные случаи использования режимов с различными типами Firewall
В ряде случаев использование различных типов Firewall может быть полезным и в случаях, отличных от типовых случаев, описанных в предыдущих разделах.
Если узел находится во внешней сети, например Интернет, имеет ее реальный адрес, сервер IP-адресов узла постоянно доступен, то при выборе режима с типом Firewall «Со статическим NAT» другие узлы, в том числе его сервер IP-адресов, будут считать этот узел, расположенным за Firewall (с внешним адресом, равным собственному IP-адресу узла). В этом случае между этими узлами вместо протокола IP/241 всегда будет использоваться протокол UDP, а главное этот узел будет доступен с других узлов не только по своему адресу, но и по некоторому виртуальному адресу, предложенному системой ViPNet. Это в ряде случаев бывает очень полезным при решении вопросов маршрутизации внутри локальной сети или организации разграничения доступа к информации по IP-адресу. Для данного случая допустимо использование и режима с типом Firewall «С динамическим NAT», но предпочтительным является тип Firewall «Со статическим NAT», поскольку в этом режиме не создается излишний трафик на свой сервер IP-адресов.
Если узел мобильного пользователя находится во внешней сети, например Интернет, имеет ее реальный адрес, но его сервер IP-адресов находится за устройством c NAT и может быть не доступен, то можно выбрать режим с типом Firewall «ViPNet-координатор», а в качестве координатора, исполняющего роль Firewall, выбрать другой постоянно доступный и не установленный ни за какие Firewall координатор. В этом случае любой трафик такого мобильного пользователя, в том числе и с его сервером IP-адресов, будет проходить через этот координатор, и пользователь сможет получить доступ ко всем ресурсам, доступным из его собственной локальной сети.
Если узел находится в локальной сети, в которой есть ViPNet-координатор, установленный на границе сети, то другие абонентские пункты этой локальной сети, как уже указывалось, целесообразно устанавливать за этот ViPNet-координатор. Вместе с тем будут работоспособны и узлы этой локальной сети, в которых выбран иной тип Firewall:
Такие возможности могут быть использованы опытными администраторами для организации различных схем маршрутизации IP-пакетов.
8. Виртуальные адреса системы ViPNet
На каждом узле ViPNet для каждого другого узла, с которым имеет связь данный узел, автоматически формируется некоторый один или более виртуальных адресов. Виртуальные адреса никак не зависят от реальных адресов узлов и привязаны на данном узле к уникальным идентификаторам узлов, присвоенным им в ЦУСе.
На каждом узле для всех узлов формируется свой набор виртуальных адресов.
Большинство приложений может использовать эти адреса при обращении на соответствующий компьютер. Драйвер системы ViPNet при отправке и получении пакетов производит необходимые подмены адресов для стандартных сетевых протоколов, в том числе для протоколов служб имен DNS, WINS, NetBIOS.
Модули ViPNet по умолчанию используют виртуальные адреса при взаимодействии с компьютерами, которые модуль ViPNet, определил, как установленные за устройства с NAT, и имеющие частные IP-адреса. При изменении расположения удаленного компьютера, что характерно для мобильных компьютеров, и получении этим компьютером вместо частного, реального адреса, автоматически изменяется статус видимости этого узла, если иное не задано пользователем.
Данная технология становится совершенно незаменимой при необходимости организации соединений между компьютерами, расположенными в подсетях с конфликтующими IP-адресами. Эта ситуация сейчас особенно часто встречается в связи с широким распространением технологий Wireless, xDSL, Home Network и др., где адреса очень часто присваиваются из одной и той же подсети, например 192.168.*.*.
Присвоенные модулем ViPNet неповторяющиеся виртуальные адреса полностью решают данную проблему. Другой областью использования виртуальных адресов является возможность их применения для разграничения доступа к информационным базам данных.
Всегда считалось, что использование IP-адреса в качестве критерия разграничения доступа в связи с возможностью его легкой подделки, является крайне ненадежным средством.
В связи с этим для разграничения доступа обычно используют пароли, формируемые с той или иной степенью сложности, но для которых, тем не менее, существует масса способов взлома.
В современных технологиях для разграничения доступа начинают использоваться технологии, основанные на инфраструктуре открытых ключей (PKI) и цифровых сертификатов. Однако при ответственном отношении к этому вопросу создание всей инфраструктуры PKI является сложной и дорогой технической задачей.
Модуль ViPNet, принимая из сети любой IP-пакет, передает его приложению, подставляя соответствующий виртуальный адрес отправителя, только в том случае, если пакет удалось расшифровать на ключах отправителя. Таким образом, обеспечивается гарантированная криптографическая защита IP-адреса от подделки, а, следовательно, и надежная криптографическая идентификация пользователя. Подделка адреса возможна только в случае, если злоумышленнику удалось завладеть соответствующими ключами. Однако сделать это через сетевые атаки практически невозможно, поскольку именно для предотвращения подобного типа проблем и предназначены технологические решения сетевой защиты ViPNet.
9. Заключение
Рассмотренные в настоящей статье методы и способы использования технологических решений ViPNet для организации безопасного соединения компьютеров в IP-сетях с непрозрачной адресацией, то есть разделенных устройствами, выполняющих преобразование адресов (NAT), решают все возникающие на сегодня практические потребности в этой области.