20. Шпаков Андрей
Ведущий инженер
Отдел технического консалтинга
Тел.: +7 (499) 940-90-61 (доб. 133)
Email: ashpakov@s-terra.ru, presale@s-terra.ru
Editor's Notes
Коллеги, Добрый день, давайте начинать. Меня зовут Шпаков Андрей. Я являюсь presale-инженером компании С-Терра СиЭсПИ. На сегодняшнем вебинаре мы обсудим тему отказоустойчивых решений наших продуктах, как они настраиваются и реализуются. Данный доклад является техническим и содержит минимум маркетинговой информации. По времени – рассчитывайте примерно на 45 минут + секция вопросов.
Если у вас возникают вопросы, задавайте их в соответствующем окне в нижней правой части экрана. По окончанию доклада я отвечу на них.. После вебинара мы разошлем ссылки на видеозапись и на презентацию всем участникам.
Итак, как будет построен данный вебинар. Вначале мы немного поговорим об определении отказоустойчивости и о том, какие узлы компоненты необходимо резервировать. Затем, мы поговорим о технологиях, которые для этого используются в шлюзах С-Терра, и об основных моментах их настройки.
Как гласит определение, Отказоустойчивость – это способность системы выполнять свое предназначение в случае отказа какого-либо из своих элементов. В хорошо организованной надежной сети отказ любого из её элементов не приведет к заметному падению уровня предоставляемых сервисов.
Если рассмотреть такой вид оборудования, как VPN-шлюз, то него есть несколько аспектов, по которым требуется резервирование:
Аппаратные компоненты шлюза.
Это непосредственно сами шлюзы
Порты на устройствах
Ну и последнее – это каналы связи, по которым шлюзы передают зашифрованные данные,
Так же стоит отметить, что в некоторых случаях сами шлюзы безопасности являются составными компонентами отказоустойчивого решения.
Далее, рассмотрим более детально каждый из этих аспектов.
Резервирование комплектующих АП. Самые уязвимые из них – это носители информации на магнитных дисках, то есть жесткие диски и блоки питания, единственные комплектующие в современных платформах имеющих аналоговые компоненты. Для старших моделей шлюзов компания С-Терра предлагает такое резервирование.
На слайде можно видеть фрагмент из нашего открытого прайс-листа, ссылка на который имеется на экране. В нем отдельные артикулы шлюзов, начиная с С-Терра Шлюз 3000 Low-end имеют полноценное резервирование аппаратных комплектующих. , Напомню, что С-Терра Шлюз 3000 low-end - это самые младшие шлюзы, которые производятся на базе полноценных серверных платформ,
Определить то, что платформа имеет резервирование, можно, посмотрев на артикул в левой части прайса. Если в нем есть обозначение RP – это означает Redundant Power Supply, то есть резервирование блоков питания в горячем резерве
Если в артикуле есть обозначение RED – это означает, что дополнительно к резерву блоков питания добавляются два жестких диска в RAID1-массиве. А , если есть обозначение RED10, то в шлюзе будет 4 диска в массиве RAID10. Отмечу ,что все реализации RAID в наших шлюзах - аппаратные.
Так же при выборе платформы нужно обращать внимание на декларируемое время наработки на отказ. Все платформы шлюзов С-Терра имеют время наработки на отказ не менее 50000 часов. Гарантия на них составляет 3 года. Напомню, что у конкурентов – только 1 год гарантии.
DEPO - 50000
EL19 – 50000
Cisco C220 - 73000
Далее, перейдем к резервированию шлюзов безопасности.
Для этого в шлюзах С-Терра используются протокол VRRP, либо технология RRI. Рассмотрим первый протокол.
VRRP это сетевой протокол, описанный в RFC 3789 и предназначенный для увеличения доступности сетевых устройств. Это достигается путём объединения группы шлюзов в один виртуальный шлюз и назначения им общих IP-адреса, которые и будут использоваться, как адреса для терминирования VPN-туннелей и как адрес шлюза по-умолчанию для компьютеров в локальной сети.
При типовом случае применения протокола VRRP два шлюза безопасности объединяются в один виртуальный. В каждый момент времени трафик обрабатывает только одно устройство. В случае его отказа — в работу включается второй шлюз. То есть мы имеем кластер вида Active-Passive.
Переключение между ними происходит за несколько секунд и обычно незаметно для конечного пользователя. После переключения происходит перестроение туннелей. Время полного восстановления работы сети зависит от многих факторов, таких как количество туннелей, терминирующихся на шлюзе, настройка таймеров DPD и др., но обычно не превышает 1 или 2 минут.
Стоит отметить, что сценарий работы данного протокола доступен как для L3-интерфейсов, так и для L2-интерфейсов.
Рассмотрим более подробно логику работы на примере кластера из двух шлюзов. Один из шлюзов настраивается предварительно, как MASTER, остальные - как BACKUP. В один момент времени виртуальный адрес (10.0.1.10 в нашем случае) может быть только на шлюзе, который находится в состоянии MASTER. Далее, MASTER-Шлюз начинает слать пакеты VRRP через интерфейсы 0/0 и 0/1 используя мультикаст адрес 224.0.0.18.
Если по причинам, описанным ниже, главный шлюз становится недоступным, его состояние меняется с MASTER на FAULT. Второй шлюз определяет отсутствие VRRP-пакетов и состояние меняет состояние с BACKUP на MASTER. Далее он отсылает так называемый GARP-пакет, чтобы обозначить коммутаторам свой MAC-адрес для обновления ARP-таблицы и продолжает заниматься обработкой трафика. При возвращении в строй главного шлюза, трафик снова будет обрабатываться на нем.
Теперь перейдем к конфигурации непосредственно на шлюзах. Протокол VRRP реализован в шлюзах безопасности S-Terra при помощи open-source проекта Keepalived
Для настройки keepalived используется файл /etc/keepalived/keepalived.conf. Данный файл разбит на блоки, каждый блок отвечает за свою часть настроек. Далее я постараюсь описать основную часть этих блоков:
Во-первых это скрипт, который отслеживает состояние VPN-демона каждую секунду. Если демон vpnsvc по каким-то причинам выгрузится, состояние шлюза изменится с BACKUP/MASTER на FAULT.
Далее синхронизация состояния двух VRRP-процессов (VRRP-instances) на шлюзе. В случае отказа одного из VRRP-процессов, для всей группы будет происходить смена состояния.
Теперь укажем параметры первого VRRP-процесса: Состояние MASTER, интерфейс, на котором работает процесс VRRP, задержку секунд перед повторной отправкой GARP после перехода в состояние MASTER, Идентификатор виртуального маршрутизатора. Обратите внимание, что для шлюзов в одном кластере и в одном бродкаст домене этот параметр должен быть идентичен.
Далее интервал отправки пакетов, параметры аутентификации, а также виртуальный IP-адрес для данного бродкаст-домена и маршрут. Обратите внимание, что задается так называемый source-маршрут. То есть при отправке пакетов по адресу 10.0.2.10 через шлюз 10.0.1.1 мы будем изменять source-адрес пакета на наш виртуальный адрес.
Далее, мы настраиваем VRRP-процесс на втором интерфейсе. Здесь все настройки те же самые, кроме virtual_router_id, адреса и самого интерфейса.
Для второго шлюза настройки идентички, кроме того, что мы указываем состояние BACKUP по умолчанию, а так же ставим более низкий параметр priority. Этот параметр сравнивается, когда устранен отказ шлюза GW1, для того, чтобы он снова стал Мастером.
Настройка в 4.2
В версии 4.2 настройка VRRP уже осуществляется через Cisco-like консоль. Здесь, по аналогии с Cisco, мы должны указать номер VRRP группы, который аналогичен параметру router_id из конфигурации 4.1, Ip-адреса на интерфейсах, параметры аутентификации и виртуальный маршрут, ну и включить дополнительные скрипты при активации состояния канала.
Таким образом в новой версии мы сделали новый шаг к унификации настройки параметров шлюза из одного интерфейса. Так же в версии 4.2 появился ряд дополнительных параметров, который позволил уменьшить время перестроения туннеля со средних 90 секунд до 30-ти.
Теперь поговорим о втором механизме отказоустойчивости для шлюзов – механизм RRI. Данная технология была разработана компанией Cisco для повышения отказоустойчивости схем подключения удаленного доступа. То есть у нас есть удаленные клиенты, которые подключаются к какому-то колличеству шлюзов, либо у нас есть классическая звезда, где spoke должны строить соединения к отказоустойчивому хабу – мы можем использовать данную технологию.
Как она работает? Как только удаленный объект строит VPN-туннель на шлюз с включенным RRI, шлюз автоматически добавляет маршшрут до этого объекта в таблицу маршрутизации. Даллее маршрут передается с помощью протокола динамической маршрутизации на балансировщик и весь обратный трафик к удаленному объекту пойдет через этот шлюз. При этом для реализации балансировки нагрузки на удаленных узлах нужно вносить в список пиров все шлюзы, а в случае мобильного клиента – включить кнопку случайного выбора пира
В отдельных случаях, когда каждый из шлюзов подключен к своему оператору, сценарий RRI позволяет резервировать и провайдеров.
Перейдем к настройке. Как видно на слайде…
Дополнительно хотел бы немного рассказать о механизме Dead Peer Detection, упомянутом в предыдущем слайде. Этот механизм является составной частью IPSec-а и предназначен для определения статуса пира.
Как он работает: каждый из партнеров проверяет наличие регулярного обмена шифрованными пакетами в рамках IKE-сессии. Если у нас идет трафик, то механизм не запускается. Как только появляется простой – запускается механизм обмена DPD-пакетами. В случае, если ответы не приходят, происходит перестроение на следующего пира в списке криптокарты.
В Cisco-like консоли он настраивается командой crypto isakmp keepalive с двумя аргументами, где первый – это промежуток простоя обмена пакетами, а второй - время между отправкой следующего DPD-пакета
Стоит отметить, что в случае использования этого механизма на нестабильных каналах связи, может потребоваться некоторая настройка. В частности, если мы хотим ослабить реакцию на кратковременные падения линка, то нам следует поднять значения retries, а не увеличивать период отсутствия трафика.
В версии 4.2 у нас появилась дополнительная настройка, отсутствующаяв Cisco IOS – это колличество пакетов, которое необходимо посылать. Меняя данный параметр, в том числе, можно ускорить переключение различных сценариев резервирование.
В завершение отмечу, что механизм DPDмы рекомендуем использовать данный механизм во всех сценариях.
Теперь перейдем к следующей задаче – резервирование портов. Для этого используется технология Link Aggregation, которая позволяет объединить несколько физических интерфейсов в один логический и базируются на стандарте IEEE 802.3ad.
Настраивается агрегация портов средстави операционной системы шлюза. Объединив два физических Гигабитных интерфейса, в ОС мы будем видеть один интерфейс, но способный работать со скоростью до 2Гбит. Влияние агрегированного канала на производительность шлюза безопасности можно считать незначительной. Накладные расходы на балансировку пакетов между физическими каналами внутри агрегированного уменьшают максимальную производительность шлюза в среднем на 5-10%.
Для контроля состояния агрегированного канала используется протокол LACP. Это публично описанный протокол и реализация его в С-Терра совместима с реализацией у других российских и иностранных производителей телекоммуникационного оборудования. Этот же протокол используется для балансировки нагрузки между каналами.
Теперь перейдем непосредственно к настройке агрегированных каналов на шлюзах. Настройка осуществляется через файл /etc/network/interfaces. Это стандартный файл в ОС Debian для внесения сетевых настроек.
Первым шагом вносим строчки, как показано на слайде. Здесь мы указываем адрес и маску нового интерфейса, его имя, какие порты будут агрегироваться (в данном случае это eth2 и eth3, режим работы LACP командой bond_mode, интервал проверки интерфейсов, а так же метод балансировки нагрузки на основе хеша от мак-адресов и ip-адресов.
Далее, перезапускаем сетевой сервис Debian-а, убеждаемся, что у нас появился новый интерфейс в системе.
Теперь нужно отердактировать файл ifalices.cf, который лежит в каталоге /etc/, добавил туда новый интерфейс, удалив eth2 и eth3. В данный файле указываются интерфейсы, на которые будет повешен драйвер С-Терра. После чего пересчитываем контрольную сумма и перезапускаем vpn-сервис.
Итак, перейдем к задаче резервирования каналов передачи данных. Начнем с
В данном сценарии рассматривается схема обеспечения отказоустойчивости с применением технологии GRE over IPsec с балансировкой по протоколу EIGRP/OSPF.
Логика работы и используемые технологии
GRE – протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Данный протокол позволяет инкапсулировать пакеты сетевого уровня в IP пакеты.
OSPF – протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology).
EIGRP – усовершенствованный дистанционно-векторный протокол динамической маршрутизации, разработанный компанией Cisco.
Шлюзы безопасности, попарно, настраиваются для работы в режиме защиты канала связи (site-to-site). Маршрутизаторы создают несколько параллельных GRE-туннелей, каждый из которых проходит через отдельный шлюз безопасности. Внутри GRE-туннелей проброшена динамическая маршрутизация EIGRP. Каждая пара шлюзов защищает один GRE туннель (пакеты GRE шифруются и попадают в IPsec туннель).
В результате такой настройки в таблице маршрутизации маршрутизатора появляется несколько маршрутов (через GRE-туннели) до удаленной защищаемой подсети с одинаковой метрикой. В результате, маршрутизатор балансирует трафик между несколькими эквивалентными маршрутами и, как следствие, между разными парами шлюзов безопасности.
Отказоустойчивость такой схемы обеспечивается за счет динамической маршрутизации. Если один из шлюзов безопасности выходит из строя, маршрут через соответствующий ему GRE-туннель автоматически удаляется. Балансировка трафика продолжается на оставшиеся в работе шлюзы безопасности.
В реальных сетях обычно применяется схема, в которой присутствует также выходной маршрутизатор, подключенный к линии провайдера.
В рамках данного решения резервируются провайдеры (каналы связи). Это достигается следующим образом: между шлюзами безопасности строится 2 GRE-туннеля. GRE-туннели, в свою очередь, инкапсулируются в IPsec. Внутри GRE-туннелей пропускается полезный трафик, а также пакеты динамической маршрутизации OSPF. Это позволяет иметь до удаленной подсети 2 равноправных (с одинаковой метрикой) маршрута. OSPF по умолчанию осуществляет балансировку между эквивалентными маршрутами по алгоритму “per-destination IP”. В случае сбоя одного из каналов связи – динамическая маршрутизация обнаружит отказ, и в таблице маршрутизации останется только один маршрут. Как следствие, весь трафик будет направлен через рабочий канал связи. Кроме того, имеется возможность построить решение без балансировки: весь трафик будет идти только через 1 канал, а второй включится в работу только при обрыве первого. Время восстановления связи при обрыве канала зависит от настроек OSPF и обычно находится в диапазоне 10-40 секунд. Важно отметить, что за счет двойной инкапсуляции (ESP+GRE) требуется несколько уменьшить MTU на интерфейсах. Стенд отрабатывает следующие типы отказов: отказ одного из провайдеров; отказ порта шлюза с одним из провайдеров.
.
Для простоты я уточнил
Так же, альтернативным методом резервирования каналов связи является исопльзование механизмов Object Tracking, то есть отслеживани какого-либо узла в интернете, и, в случае его недостуности, переключение на резервный канал.
Для наших шлюзов версии 4.1 имеется такой сценарий при использовании скрипта. Я не буду приводить сюда полный текст, с ним вы сможете ознакомиться в соответсвующем сценарии на сайте, а приведу логику работы и основные параметры.
; По умолчанию существует оба маршрута через основного и резервного провайдера. Маршрутизация определяется метрикой маршрута. Метрика через основного провайдера – 100, метрика через резервного провайдера – 200. Трафик идет через основного провайдера. Через каждые N секунд (количество секунд определяется переменной PING_TIMEOUT) запускается утилита ping на отправку 1 ICMP-запроса. С каждым неполученным ICMP-ответом число PING_COUNT уменьшается. При получении ICMP-ответа число PING_COUNT возвращается в изначальное значение. Если PING_COUNT доходит до нуля, то метрика через резервного провайдера становится – 100, а через основного – 200. Трафик начинает идти через резервного провайдера. При этом ICMP-запросы через основного провайдера продолжают отправляться. При получении ICMP-ответа интервал между ICMP-запросами становится в значение RESTORE_PING_TIMEOUT. После получения подряд N пакетов (количество пакетов определяется переменной RESTORE_PING_COUNT) происходит обратное переключение на основного провайдера. Если ICMP-ответ не приходит счетчик ICMP- ответов сбрасывается. При переключении провайдера происходит перезагрузка политики безопасности (lsp_mgr reload), а в лог добавляется сообщение о переключении.