Сопряжение с сетями смежных организаций

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

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

Из опыта обследования и модернизации различных сетей мы можем сказать, что задачу взаимодействия между разными организациями часто решают “спустя рукава”. Пожалуй, наиболее красочным здесь будет следующий пример:

Здесь две организации по стечению обстоятельств находятся в одном здании, поэтому они решили организовать связность, объединив между собой коммутаторы доступа. Связность достигнута? Конечно. Тогда в чем вопрос? Насколько надежным будет такое решение. К примеру, потребуется администратору внести настройки в коммутатор доступа (в организации с большим количеством пользователей – вполне частая операция). Сыграет роль человеческий фактор, и настройки для новой рабочей станции по ошибке применятся на порт в направлении смежной организации, в результате чего связь прервется. Просто потому, что одно и то же устройство выполняет две принципиально разные роли – коммутатор доступа и коммутатор модуля взаимодействия со смежными системами.

Однако, чаще приходится встречать картину, когда для взаимодействия между организациями используется инфраструктура оператора связи. А в случае, когда доступ к ресурсам критически важен, то операторов связи как минимум два. Вот только зачастую заметается под ковер вопрос – как контролируется доступность ресурса и кто отвечает за выбор канала связи? Вопрос, вроде бы, очевидный, но решение его не всегда простое. Точнее, самое простое решение мы часто наблюдаем – доступность контролируют пользователи, которые в случае аварии звонят администратору и, если тот на рабочем месте, то вручную вносит настройки, позволяющие перенаправить трафик на работоспособный канал. И хорошо еще, если такая процедура хоть как-то отработана и проверена. Знакомая ситуация? Вопрос риторический.

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

Начнем обсуждение проблемы издалека, а точнее, с разделения задачи обеспечения связности на Control Plane и Data Plane.

С точки зрения Control Plane необходимо решать следующие задачи:

• контроль доступности активов через каждый из каналов связи
• переключение трафика на работоспособный канал в случае отказа

Кроме того, при взаимодействии между организациями должны существовать механизмы изоляции Control Plane друг от друга.

С точки зрения Data Plane стоит обеспечить как минимум два канала связи к разным операторам с разных площадок.

В дополнение, если речь идет о предоставлении доступа к собственным ресурсам организации, важную роль играет адресация. А именно, используются ли для адресации приложений Provider Independent Address (PIA) или Provider Aggregatable Address (PAA).

В итоге, к рассмотрению в этой статье я предлагаю 4 сценария:

Начнем с наиболее, пожалуй, распространенного сценария, когда необходимо предоставить пользователям доступ к активам смежных организаций. Исходные условия: два оператора связи, каждый из них выделяет диапазон собственных (PAA) адресов для подключения к своей инфраструктуре. Оператор для подключения организации использует статическую маршрутизацию. Я отобразил это на следующей схеме:

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

В пределах собственной сети работает протокол динамической маршрутизации (OSPF, BGP), который позволяет парировать ситуацию отказа канала связи в пределах собственной сети организации. Однако он не в состоянии сообщить об изменениях на стороне операторов. К примеру, если актив перестает быть доступен через Оператора 1 из-за проблем внутри инфраструктуры оператора, пользователи Площадки 1 будут по-прежнему направлять трафик через R1, где он будет отброшен.

Для решения этой задачи предлагается использовать механизм под условным названием Edge Tracker (у разных производителей оборудования он имеет разные названия, я предпочел выбрать нейтральный термин). Идея механизма такова: на пограничном устройстве запускается процесс, который контролирует доступность Актива через выбранный интерфейс. Контроль может выполняться с использованием запросов ICMP или TCP (в зависимости от от реализации).

В случае, если Актив перестает быть доступен, Edge Tracker инициирует процедуру удаления статического маршрута из таблицы маршрутизации. В результате, за счет работы протокола динамической маршрутизации внутри организации, трафик перенаправляется через другое пограничное устройство, для которого Актив по-прежнему остается достижим:

Особенность этого сценария в том, что сама собой решается проблема симметрии входящих и исходящих потоков трафика (симметрия необходима пограничным устройствам UTM для принятия решения о пропускании или отбрасывании проходящих пакетов в связи с принадлежностью к уже установленной сессии). Вследствие того, что для связи с операторами используется адресация PAA, на устройствах UTM выполняется NAT, причем, на каждом устройстве – в свой пул адресов. Со стороны же Актива (для ответного трафика в организацию) маршрут к каждому из пулов однозначно определяется принадлежностью этого пула первому или второму оператору.

Следующий сценарий – организация доступа к собсвенным активам организации. Условия те же – два оператора и автоматическое парирование отказов.

В этом случае я предлагаю использовать механизм Global Site Load Balancing (GSLB). Для его реализации потребуются следующие компоненты:

• приложение, способное быть запущенным в нескольких экземплярах на разных площадках (а как иначе, ведь это критически важное приложение?)
• authoritative DNS, находящийся под собственным управлением

Схематично решение отображено далее:

В штатном режиме работы сервер DNS возвращает две записи типа A, и клиент сам выбирает, к какому из экземпляров приложения подключаться. В дополнение (и в этом, можно сказать, секретный соус решения), сервер DNS контролирует состояние локальной копии приложения и состояние каналов связи с операторами. В случае недоступности сервер принимает решение об удалении соответствующей записи, и уже на следующий запрос он вернет всего одну запись типа А.

Предвижу как минимум два вопроса (возможно и больше – задавайте в комментариях). Во-первых, встроен ли функционал контроля в стандартные продукты DNS (к примеру, входящие в дистрибутивы Windows или Linux)? Не готов дать положительный ответ. По крайней мере, мне о таких неизвестно. Однако, на рынке достаточно много специализированных GSLB решений от различных производителей, которые в состоянии решить описанную задачу. Или организация может выбрать свой путь, самостоятельно разработав логику работы такого трекера (к примеру, с использованием bash или powershell).

И второй вопрос – что с теми пользователями, которые подключились к приложению до того, как случилась авария? Действительно, в предлагаемом решении оповестить их можно только по DNS, а новых запросов к DNS они делать не будут как минимум пока не истечет таймаут для предыдущего локально закэшированного ответа.

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

Для приложений, отличных от веб, все может быть более индивидуально с точки зрения кэширования в клиентском ПО. Однако и здесь можно найти подходы к решению. Базируется  это решение на использовании параметра TTL в настройках ресурсных записей DNS. Этот параметр задает время, в течение которого промежуточные серверы DNS, а также операционная система клиента должны кэшировать полученный ответ. В идеальном мире, задав нужное значение этого параметра (например, 5 минут), можно обеспечить требуемый интервал переключения на работоспособный ресурс. Однако, зачастую, для облегчения собственной работы, этот параметр увеличивается промежуточными серверами DNS (бОльший интервал кэширования = меньшая частота запросов = меньшая нагрузка). Как следствие, нет гарантии того, что клиенская операционная система получит именно то значение TTL, которое задумывал владелец ресурса. К сожалению, других более надежных инструментов способ с DNS не предполагает, и уже подключенные к Активу клиенты могут испытать перерыв в сервисе на время, зависящее от настроек сервера DNS их провайдера .

На этом закончим рассмотрение сценариев с Provider Aggregatable адресацией и перейдем к сценариям Provider Independent.  Схематично решение представлено на следующем рисунке:

Для обмена маршрутной информацией с операторами задействуется динамический протокол маршрутизации (вероятнее всего, это BGP). Вследствие этого нет необходимости отдельно рассматривать сценарии доступа к внешним активам и публикации собственных активов. Отказы в обоих случаях обрабатываются одними и теми же инструментами – стандартными средствами протокола BGP (сообщения update, манипуляция метриками). Подробнее о возможных отказах и подходах к их парированию можно узнать из слайдов соответствующей презентации с семинара. Отмечу, что предлагаемая схема отличается от схемы, используемой в решении с PAA наличием дополнительного канала связи (EQ-link, equalization link). Задача этого канала – обеспечивать симметрию прохождения потоков трафика через устройства UTM. На схеме это реализовано в виде двух дополнительных маршрутизаторов на границе сетей.  Для обеспечения симметрии также используются инструменты BGP.

Подводя итоги статьи, хочу обратить внимание на особенности того или иного решения (заодно и освежу их в вашей памяти).

Итак, если в наличии есть два оператора и адресации PAA (что, безусловно, гораздо привычнее с точки зрения административных процедур), можно организовать доступ к активам смежных организаций с использованием технологии Edge Tracker. Единственной особенностью подхода является необходимость поддержки этого функционала на пограничных устройствах – это не стандартный механизм, производители реализуют его по-разному.  Похожая картина и с публикацией собственных ресурсов. Предлагаемое решение – GSLB, за реализацией необходимо обращаться к одному из производителей продуктов этого класса.   В обоих случаях решение предполагает время реакции на отказ порядка минут (по крайней мере, для веб-приложений).

В случае, если организация принимает решение использовать PIA, то она получает универсальный инструмент – BGP – как для решения задачи доступа к внешним активам, так и для публикации собственных активов. Но, такой подход выбирают далеко не все, в силу административной сложности получения в пользование пула адресов размером не менее /24 для каждой из площадок. Однако, сложно – не означает невозможно.

Описанные подходы, безусловно, не покрывают все возможные способы решения поставленной задачи. Однако, именно они чаще всего используются на практике, а, следовательно, являются наиболее проверенными и готовыми к “боевому” применению.

Пробуйте, делитесь комментариями и замечаниями.