Настройка резервного канала связи

Бесперебойный доступ к сервисам и ресурсам в современном мире — крайне, иногда даже «жизненно», необходим. Для того, чтобы все работало без сбоев, необходимо позаботиться о резервировании каналов доступа.

В этой статье мы расскажем, как настроить резервный канал доступа, если произошёл сбой.

Содержание:

С обновлением версий нашего программно-аппаратного комплекса (ПАК) для защиты каналов связи и его виртуализированного двойника появилась функция автоматического переключения каналов связи в случае недоступности основного канала.

Данная функция получила название Dead Gateway Detection — сокращенно DGD.

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

Давайте рассмотрим настройку данной функции при помощи web-интерфейса на примере нашего ПАКа, на котором проведена первичная инициализация и настроены интерфейсы. Шлюз безопасности имеет два канала связи, через который осуществляется доступ в интернет: основной через GW1 и резервный через GW2 (схема 1).

Предположим, что на основном канале GW1 произошёл сбой. Перед нами встаёт задача — переключить трафик на резервный канал доступа в Интернет через маршрутизатор GW2.

Настройку данной функциональности можно разделить на 3 последовательных шага:

Подключение по web-интерфейсу возможно только удалённо с другого защищённого узла. Есть такая примета: удалённая настройка маршрутизации и правил межсетевого экранирования — к дальней дороге! Поэтому мы и подготовили этот материал, чтобы помочь вам избежать ошибок.

Надо отдавать себе отчёт, что настройка маршрутизации на ПАК, как и на любом сетевом оборудовании, довольно ответственное мероприятие. В случае ошибки администратора при удалённой настройке есть большой риск нарушить работоспособность сети и потерять доступ к ПАК.

Если вы осознаёте все риски, сделали все возможные резервные копии, подготовили план «Б» в виде специалистов на объекте, которые могут произвести настройку локально, в этом случае можно приступать к настройке.

На координаторах можно выделить 2 типа таблиц маршрутизации (в контексте настройки DGD протоколы динамической маршрутизации не рассматриваем):

Перед настройкой давайте посмотрим на схему 1 и определим, какие маршруты необходимо добавить.

К координатору напрямую подключены подсети 10.2.0.0/24, 198.51.100.32/27 и 203.0.113.16/28. Дополнительно необходимо создать статические маршруты в подсети 10.15.0.0/24, 10.25.0.0/24 и 10.77.0.0/24.

Для просмотра таблиц маршрутизации необходимо перейти в раздел «Сетевые настройки» на главной странице интерфейса ПАК. В нём вы найдете вкладку — «Маршрутизация». В ней мы сразу попадаем в сводную таблицу:

Сейчас в таблице маршрутизации имеются маршруты только в directly connected подсети интерфейсов и создан один статический маршрут — маршрут по умолчанию через шлюз 198.51.100.33.

Для просмотра статической маршрутизации необходимо перейти в соответствующую вкладку:

Для добавления маршрутов необходимо перейти в режим администрирования ПАК. Для этого в web-интерфейсе нажмите кнопку «Войти как администратор».

Приступаем к настройке.

Статические маршруты в подсети 10.15.0.0/24, 10.25.0.0/24 и 10.77.0.0/24 всегда должны идти через маршрутизатор 10.2.0.10, вне зависимости от доступности внешних каналов связи. Добавляем эти маршруты в таблицу по умолчанию.

В web-интерфейсе необходимо нажать кнопку «Добавить маршрут», после чего откроется меню добавления маршрута:

В окне «Таблица маршрутизации» необходимо выбрать в какую таблицу нужно добавить маршрут.

Для добавления маршрута в таблицу по умолчанию необходимо выбрать из списка «По умолчанию».

В поле «Номер и название» вводим номер пользовательской таблицы и ее имя. Для уже существующих таблиц, в том числе и таблицы по умолчанию, данные параметры отсутствуют.

В поле «Подсеть назначения» два окна. В первом указываем стартовый адрес подсети, во второй — маску. Если необходимо добавить шлюз по умолчанию, то данные параметры заполнять не нужно.

Поле «Адрес шлюза» предназначено для адреса маршрутизатора, через который необходимо осуществлять передачу трафика.

«Дистанция» и «Вес» необходимы для настройки балансировки трафика или резервирования маршрутов, в нашем случае данные параметры необходимо оставить по умолчанию.

Вот так должна выглядеть настройка маршрута в сеть 10.15.0.0/24 через шлюз 10.2.0.10 в таблице по умолчанию:

По аналогии добавляем маршруты в подсети 10.25.0.0/24 и 10.77.0.0/24.

Создадим маршрут по умолчанию через GW1, добавим его в новую таблицу с именем def-gw1 и присвоим номер 1024:

Так же настраиваем маршрут через GW2 с именем таблицы def-gw2:

В результате у нас должны получиться 3 статические таблицы:

В сводную таблицу пользовательские статические таблицы не попадают. Для их просмотра необходимо выводить именно статические маршруты. Не забываем, что шлюз по умолчанию настроен через маршрутизатор 198.51.100.33, информация об этом содержится и в таблице по умолчанию, и в таблице 1024 def-gw1. Это важный момент при удалённой настройке.

Мы настроили статические таблицы маршрутизации. Еще раз проверьте, что вы ничего не забыли.

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

По умолчанию используется стандартная политика («Политика маршрутизации по умолчанию»), в которой используется только таблица по умолчанию.

Для просмотра в web-интерфейсе перейдите на вкладку «Политики маршрутизации», активная политика помечается иконкой звездочки слева от имени:

Для реализации функционала резервирования нам необходимо обеспечить работу 2-х схем:

Для первой схемы маршруты в подсети 10.15.0.0/24, 10.25.0.0/24 и 10.77.0.0/24 и directly connected сети (доступ к маршрутизаторам) содержатся в таблице по умолчанию. Для направления внешнего трафика через 198.51.100.33 необходимо использовать таблицу 1024.

Схематично это показано на схеме 2.

Для создания политики маршрутизации нам нужно указать какую таблицу и с каким приоритетом необходимо использовать.

При формировании политики таблицы не суммируются, соответственно, сначала проверяется более приоритетная таблица. Внутри таблицы приоритетны маршруты с более узкой маской. Если подходящий маршрут не найден, то проверяется следующая по приоритету таблица и так далее, пока не закончатся таблицы или не будет найден маршрут.

Соответственно если мы в политике укажем с максимальным приоритетом использовать таблицу def-gw1 или def-gw2, то любой трафик будет отправлен на шлюз по умолчанию из этой таблицы, даже в подсети 10* и к directly connected. Это приведет к сбою в работе сети, потому что необходимые маршруты не содержатся в таблице по умолчанию, а до нее очередь не дойдет. Будьте внимательны, это очень важный момент!

Для формирования политики маршрутизации в web-интерфейсе нажмите кнопку «Добавить правило»:

В поле «Политика маршрутизации» нужно указать имя политики, в которую будет добавлено правило. Для создания новой политики необходимо ввести уникальное имя. Кроме этого вы можете выбрать уже существующую политику.

Поле «Приоритет» предназначено для указания приоритета выполнения правила внутри политики, значение от 1024 до 2048. Чем ниже значение, тем выше приоритет, соответственно, правило с номером 1024 имеет максимальный приоритет и выполняется в первую очередь. Напоминаем, что с приоритетом 1024 необходимо во все правила добавлять таблицу по умолчанию.

В поле «Обработка» необходимо выбрать значение «По таблице», далее указать имя таблицы.

Поле «Признаки трафика» в нашем сценарии добавлять не нужно, его оставляем пустым.

Создадим правило для политики GW1-policy, в котором с максимальным приоритетом используется таблица по умолчанию:

Добавим в политику GW1-policy правило использовать таблицу 1024 (def-gw1) с приоритетом 1025:

По аналогии создадим правила в новой политике GW2-policy: с приоритетом 1024 используется таблица по умолчанию и с приоритетом 1040 используется таблица 1025 (def-gw2).

В результате должны получиться 3 политики:

Разный приоритет для таблиц маршрутизации def-gw1 (1025) и def-gw2 (1040) в политиках выбран для наглядности.

В политике GW1-policy мы не можем между правилами добавить при необходимости дополнительные условия. Для этого нужно будет удалять правило с приоритетом 1025, после чего создавать дополнительные условия и в конце с минимальным приоритетом создавать правило направления трафика через таблицу def-gw1.

В политике GW2-policy мы оставили себе место для дополнительных условий. Для этого нужно будет создавать правило с приоритетом 1025-1039. Мы рекомендуем при настройке правил маршрутизации делать промежутки между приоритетами для возможности удобного администрирования в дальнейшем.

Все помнят, почему таблица по умолчанию включена во все политики маршрутизации с максимальным приоритетом?

Еще раз внимательно проверьте, что вы ничего не забыли: все необходимые маршруты и пользовательские таблицы созданы, в политики маршрутизации добавлены соответствующие таблицы, приоритеты расставлены правильно. Тогда переходим к следующему пункту.

Функция DGD работает следующим образом: мы указываем несколько адресов. Это могут быть адреса маршрутизаторов или ресурсов, доступность которых проверяется системой. Проверки могут происходить по одному из следующих протоколов: icmp, tcp:80 или tcp:443. На основании результата проверок доступности активируется одно из правил DGD.

Настройка DGD осуществляется только при включенной службе. По завершению настройки для применения изменений в правилах DGD необходимо службу перезапустить.

Для примера не будем усложнять настройки, проверим доступность самих маршрутизаторов GW1 (198.51.100.33) и GW2 (203.0.113.17) по протоколу icmp.

Для этого в web-интерфейсе необходимо перейти в основном меню в раздел «Сетевые настройки», в котором будет вкладка «Маршрутизация» — «Обнаружение недоступных шлюзов». Включаем сервис.

Для добавления адреса необходимо нажать кнопку «Добавить шлюз»:

Поле «Статус» предназначено для включения/выключения проверки адреса.

В поле «Название» указываем произвольное имя шлюза.

Поле «IP-адрес или интерфейс» предназначено для ввода адреса шлюза, через который необходимо осуществлять маршрутизацию к проверяемому IP-адресу.

В поле «Протокол» указываем протокол проверки icmp, tcp:80 или tcp:443.

Поле «Тестовый IP-адрес» предназначен для IP-адреса узла, доступность которого мы будем проверять.

Для настройки проверки адреса шлюза 198.51.100.33 по протоколу icmp необходимо ввести следующие параметры:

Аналогично добавим проверку адреса 203.0.113.17.

В результате мы должны получить следующее:

Зеленая галочка означает, что оба канала доступны.

Переходим к написанию правил DGD.

Как и при создании политик маршрутизации в одном правиле может быть несколько условий и действий. Каждое условие и действие настраивается отдельно.

Для нашего примера достаточно создать два функциональных правила DGD, которые бы проверяли доступность шлюзов и переключали политики маршрутизации:

И одно информационное:

В нашем сценарии нет необходимости дополнительно активировать какие-либо политики. В случае недоступности обоих маршрутизаторов трафик во внешнюю сеть не будет передаваться, а внутренние подсети доступны при любой активной политике, т.к. все необходимые для этого маршруты содержатся в таблице по умолчанию. Как мы помним, данная таблица в обеих политиках маршрутизации обрабатывается с максимальным приоритетом.

Для настройки правил в web-интерфейсе необходимо перейти в раздел «Сетевые настройки» — «Маршрутизация» — «Обнаружение недоступных шлюзов» — «Правила переключения». Для создания правила нажмите кнопку «Добавить правило»:

В поле «Название» вписываем имя правила.

В поле «Активировать политику» при установке флага появится возможность выбрать политику маршрутизации, которую необходимо активировать.

Поле «Записать в системный журнал» предназначено для того, чтобы при срабатывании правила в системном журнале появилось сообщение.

При нажатии кнопки «добавить» в поле «Условия срабатывания» можно будет выбрать проверяемый шлюз и его состояние.

Например, для создания правила general, которое отвечает за активацию политики GW1-policy, необходимо настроить следующие параметры:

По аналогии создадим оставшиеся правила: reserve, активирующее политику маршрутизации GW2-policy, и all-gw-down. В результате у нас должны быть настроены 3 правила:

Для активации правил переключения необходимо перезапустить службу DGD в web-интерфейсе.

Дополнительно можно настроить параметры проверки доступности. Для этого перейдите в «Проверка доступа к шлюзам» и нажмите кнопку «Параметры проверки»:

По умолчанию настройки следующие:

Мы рекомендуем оставить эти значения. Они обеспечивают баланс между временем переключения канала и вероятностью ложного детектирования недоступности проверяемого ресурса.

Логика работы следующая: раз в «Интервал между проверками…» отправляется запрос на проверяемый ресурс в соответствии с настройками. В нашем случае это будут icmp-запросы. Если в течение «Время ожидания ответа…» ответ приходит, то счетчик «Число проверок…» сбрасывается к значению 0, к времени ответа прибавляется «Интервал между проверками…» и посылается очередной запрос на проверяемый ресурс.

Если ответа нет, то ожидаем до конца «Время ожидания ответа…», прибавляется «Интервал между проверками…» и посылается очередной запрос на проверяемый ресурс.

Общая формула выглядит следующим образом: время переключения канала = «Число проверок…» * («Время ожидания ответа…» + «Интервал между проверками…»).

При таких настройках максимальное время переключения канала займёт около 20 секунд.

Это происходит, когда проверяемый ресурс перестаёт быть доступным. Минимальное время переключения канала составляет около 10 секунд в момент, когда проверяемый ресурс становится доступен и отвечает с задержками в несколько миллисекунд.

Далее проверим активную политику маршрутизации. Она должна переключиться с default на одну из настроенных. В нашем случае это GW1-policy:

Политики переключились, значит правила DGD отработали корректно.

Сейчас необходимо проверить, что при недоступности шлюза 198.51.100.33 произойдет переключение на политику GW2-policy. Мы можем отключить интерфейс или выдернуть патчкорд. Это приемлемо при локальной настройке.

При удалённой настройке мы точно потеряем доступ к ПАК, так как у нас в таблице по умолчанию прописан шлюз 198.51.100.33 для всего трафика. Чтобы этого избежать, мы просто заблокируем исходящий icmp-трафик на адрес 198.51.100.33.

Создаём правило в локальных фильтрах открытой сети:

Перемещаем его наверх, предоставляя максимальный приоритет и применяем изменения.

В результате адрес шлюза GW1 в настройках DGD станет недоступным:

Произойдёт переключение политики маршрутизации на GW2-policy.

Напоминаем, что у нас в таблице по умолчанию всё ещё находится маршрут по умолчанию через 198.51.100.33. Таблица по умолчанию имеет более высокий приоритет, нежели таблица def-gw2. Соответственно, даже при переключении политики, маршрутизация не поменяется и мы не потеряем удаленный доступ до координатора.

Удаляем правило и проверяем, что политика переключилась обратно на GW1-policy.

Проверки пройдены. Политики переключаются корректно.

Теперь пора удалить маршрут по умолчанию через шлюз 198.51.100.33 из таблицы по умолчанию. Напоминаем, что шлюз по умолчанию должен содержаться только в самой низкоприоритетной статической таблице маршрутизации.

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

Напоминаем, что при использовании политик маршрутизации не строится сводная таблица всех активных маршрутов. Необходимо просматривать вкладки «Сводная таблица» и «Статические». Активную политику смотрим во вкладке «Политики маршрутизации», она отмечается звёздочкой.

Давайте проверим, как же реагируют другие узлы защищенной сети на переключение шлюзов на координаторе. Мы собрали стенд, в который добавили второй координатор и туннелируемые ресурсы (схема 3).

В первом сценарии мы будем запускать пинг с туннелируемого ресурса 1 на туннелируемый ресурс 2 (схема 4).

Источник трафика находится внутри сегмента, на границе которого произойдёт смена канала.

Для внешних защищенных узлов это самый легкий сценарий, т.к. информация об изменениях в адресе доступа координатора будет сразу же направлена после смены канала. Для проверки отключим интерфейс с адресом 198.51.100.54 на координаторе номер 1.

Как видим, потеряно 4 пинга, что соответствует примерно 20 секундам. Обратное переключение происходит без потери пингов, т.к. становятся доступны оба канала и очередной пакет просто будет отправлен по новому маршруту при переключении политики. Для переключения каналов требуется около 10 секунд. Это совпадает с логикой таймингов задержек при переключении канала, описанной в 3-ем разделе.

Во втором сценарии запускаем пинг в обратном направлении: с туннелируемого ресурса 2 на туннелируемый ресурс 1 (схема 5).

Это усложняет задачу, т.к. «внешний» координатор 2 не знает о смене адреса доступа и продолжает посылать трафик на «старый» адрес.

Так же, отключаем интерфейс с адресом 198.51.100.54 на координаторе 1.

Задержка ответа может составить от 25 секунд до 1 минуты 20 секунд (20 секунд — задержка определения недоступности адреса проверки в DGD). Кроме этого от 5 секунд до 1 минуты дополнительного времени может понадобиться на рассылку информации о смене адреса внешним узлам. Это обусловлено механизмом работы межузловых рассылок, которые периодически происходят между защищенными узлами, обменивающимися трафиком.

В третьем сценарии мы усложним задачу ещё больше: в момент, когда между координаторами 1 и 2 нет обмена трафика, произведем отключение интерфейса с адресом 198.51.100.54 на координаторе 1.

После этого запустим пинг с туннелируемого ресурса 2 на туннелируемый ресурс 1. Источник трафика, как и во втором сценарии находится с внешней стороны, координатор 2 не знает о переключении канала и при этом между ними нет трафика и, соответственно, межузловых рассылок. В таком случае задержка может составлять до 15 минут. За это отвечает параметр server_pollintervall в iplir.conf (server_pollinterval — период опроса данным координатором других координаторов). Если от какого-либо координатора, который должен обмениваться пакетами с данным координатором, не было получено никаких служебных пакетов в течение времени, указанного в данном параметре, то такому координатору направляется специальный пакет, на который должен прийти ответ. Если ответ не приходит, то узел координатора считается недоступным (выключенным). Указывается в секундах. Значение по умолчанию — 900 (15 минут).

В действительности речи о 15 минутах не идет, т.к. каждый координатор опрашивает известные ему узлы и время опроса не синхронизируется, у каждого узла свой счетчик. Чем больше узлов в связях у координатора, тем выше вероятность того, что будет произведен опрос адресов доступа или запустится механизм межузловых рассылок, что приводит к задержке всего в несколько минут. Мы не рекомендуем значительно уменьшать данный параметр, т.к. при этом повышается генерация служебного трафика. В больших сетях это может привести к снижению производительности. Для каждого координатора данный параметр должен подбираться индивидуально, в зависимости от количества связей и нагрузки.

Поздравляем, вы дочитали статью до конца! А если серьезно, мы хотим поблагодарить вас за время, уделенное данной статье. Мы подробно рассмотрели пошаговую настройку переключения на резервный канал доступа. Эта же инструкция применима и для настойки виртуального шлюза безопасности.

Для настройки требуется понимание логики работы и внимательность. В случае возникновения проблем вы всегда можете обратиться в нашу службу технической поддержки hotline@infotecs.ru или обратиться в телеграм-канал техподдержки.