Как мы переделали сеть «Аэроэкспресса»: интересный пример скачка на уровень вверх
«Аэроэкспресс» — молодая компания. Пару лет назад, когда мы начали реализовывать проект по модернизации сети передачи данных, компания очень быстро развивалась. Настолько быстро, что их внутренний ИТ-отдел в какой-то момент понял: пора переделывать сеть, потому что пунктов продажи билетов и других терминалов стало слишком много и ручные процедуры настройки сети уже давно пора заменять. Это логический этап в эволюции любой компании. На этом этапе заказчик продумал правильную архитектуру и начал оптимизировать инфраструктуру с учётом запаса прочности при дальнейшем масштабировании мощностей. Цель — сделать всё и с первого раза, чтобы избежать возможных проблем в будущем.
Основная задача заключалась в разделении корпоративной сети, в одной из которых находятся пользователи и терминалы касс, а в другой осуществляются непосредственно денежные транзакции. Пересекаться они ни в коем случае не должны. Идеальный выход в данной ситуации — физически разграничить сети, то есть построить две независимых. Однако это довольно дорого. Поэтому почти идеальным решением стал правильный выбор и настройка сетевого оборудования. В нашем случае это были аппаратные фаерволы.
Следующей задачей стало обеспечение возможности продавать билеты, даже если метеориты попадут в два любых случайных объекта инфраструктуры (включая дата-центр «Аэроэкспресса» и коммутаторы ядра М9).
И ещё — сделать IP-телефонию внутри компании, способной работать даже при физическом отключении от интернета.
Параллельно мы подняли Ethernet поверх IP (MAC по IP) и сделали ещё пару забавных и полезных фич.
Как это было, как это делают банки, и как это сделать дешевле
На момент начала проектирования новой архитектуры сети у заказчика была довольно простая топология: основной дата-центр с общими серверами и машинами «с деньгами», резервный ЦОД, машины офисных сотрудников и терминалы по продаже билетов, в том числе в поездах. На каждой оконечной точке сети был поднят тот или иной аплинк, причём именно провайдеры обеспечивали по контракту туннелирование, защиту, фильтрацию трафика и прочие сервисы, которые должна делать корпоративная сеть. Заказчик сильно зависел от возможностей провайдеров, условия контрактов были жёстко зафиксированы. Например, заказчик не мог видеть критичное для себя оборудование, т. к. оно было в собственности провайдера. Соответственно, «Аэроэкспресс» мог оперативно реагировать на сбой связи либо быстро, но силами всех сисадминов вручную, либо в SLA провайдера, а это обычно 24 часа минимум. А как вы, наверное, догадываетесь, даже пара минут простоя продажи билетов — это катастрофа. Кризиса ждать не стали. Команда заказчика хорошо понимала ограничения архитектуры, правильно предвидела риски и решила предотвратить проблему до её появления.
Банки в такой ситуации соединили бы все свои основные филиалы (по одной точке на вокзалах в Москве, аэропортах, вокзалах других городов и центре разработки в Петербурге, а также в своих дата-центрах) своими собственными каналами оптики. Поскольку это не просто дорого, а очень дорого, естественно, что кроме банков, крупных госкомпаний и сотовых операторов мало кто может себе такое позволить. Поэтому оптимальное решение — создание единой виртуальной сети, где весь трафик до конечных пользователей завёрнут в туннель и стойко зашифрован.
Виртуальная сеть с единой адресацией, чтобы сервер дата-центра видел и разработчика в Петербурге и терминал в Шереметьево как машины в своей локальной сети, позволяет полностью абстрагироваться от уровня железа и переключать провайдеров прямо на точках, меняя канал. Именно это и стало, наверное, самым затратным пунктом в рамках проекта — нужно было закупить и поставить оборудование на все узлы.
Архитектура
Дата-центров два: первый ЦОД в Шереметьево (основной), а второй вообще на М9.
Изначально архитектура ЛВС в центральном узле связи представляла собой плоскую сеть с одним коммутатором ядра, все остальные коммутаторы были исключительно коммутаторами доступа, без резервного подключения. Проектное решение подразумевало переход на отказоустойчивое подключение, к уже существующему коммутатору ядра подключался второй. Работы по интеграции можно было сделать только в очень короткий ночной промежуток времени, чтобы не нарушить работы бизнес-систем. Поэтому тщательно прорабатывался план миграции, в соответствии с которым работы проводили в несколько этапов.
Поменялась вся схема IP-адресации. Все подключения резервировались. Какое-то время параллельно существовало две сети, и только после того как прошло опытное двухнедельное тестирование, ядро сети было смигрировано на новое оборудование. Параллельно с модернизацией сетевой инфраструктуры на всех объектах компании была создана новая инфраструктура в ЦОД. Для работы информационных систем использована технология передачи данных Ethernet поверх IP-сетей, т. н. «MAC в IP».
Заказчик правильно подошёл к вопросу об уровнях доступности сервисов и сразу расставил приоритеты (обычно на производствах и даже в банках легко определить один-два критичных сервиса, но дальше начинаются сложности). Главным стало то, что находится в зоне Cash: платёжные системы, где постоянно крутятся транзакции за билеты. Меньший приоритет в части спасения на резервную площадку получили системы обслуживания поездов (депо, инженерные подсистемы) и документооборот. Если упадут они, то мотор чинить не перестанут, хотя придётся писать много на бумаге, чтобы потом занести информацию в ИТ-системы, когда сеть поднимется.
ИТ-служба «Аэроэкспресса» выделила внутри себя собственную службу администрирования. До этого заказчик не мог администрировать инфраструктуру полноценно, поскольку оборудование было не его. Теперь «Аэроэкспресс» видит каждую железку удалённо, может реагировать на инциденты и проводить регламентные работы.
Переключение между провайдерами последней мили делается прямо на роутерах в режиме Watchdog — они смотрят за качеством канала и при достижении граничных условий просто меняют его. Кроме двух active-active линий в резервном случае в строй может вводиться и третий отдельный провайдер (это особенно касается офиса).
Вот так это выглядит с точки зрения безопасности:
Слева отображены две внутренние зоны, созданные на МСЭ, — это Inside (общая зона для внутренних служб) и Cash (особо защищённая зона кассового сегмента). В кассовую зону входили АРМ кассиров на вокзалах и в аэропортах, а также билетные автоматы. На взаимодействие Cash с остальными участками накладывались самые жёсткие ограничения и наиболее строгие правила сканирования трафика на предмет вредоносов. В зону Inside входят остальные службы компании: телефония, видеонаблюдение, управление устройствами и общий внутренний сегмент пользователей, где-то ещё был гостевой Wi-Fi. Эти участки разделены по VLAN’ам, которые терминировались на оборудовании Palo Alto. Оборудование, стоявшее в зоне Inside, — это коммутаторы, телефоны, видеокамеры, точки доступа, обычные компьютеры пользователей.
До этого, напомню, пользователи и системы имели одинаковые права. Ролей и зон доступа не было, поэтому грамотно развёрнутый зловред где-нибудь на Курском вокзале в терминале продажи билетов мог бы, в теории, положить всю систему. Сейчас все правильно изолированы.
Доступ изнутри наружу осуществлялся через созданные зоны Outside, Internet и VPN (изображены справа). Outside — это внешний WAN-сегмент, туда подключались маршрутизаторы. Internet — это интернет, туда подключалась последняя миля от провайдера. VPN — это зона для VPN-подключений к дата-центру. VPN использовался для резервирования WAN-канала. В случае падения WAN-канала трафик шёл через VPN. На некоторых сайтах это был единственный способ доступа к корпоративным ресурсам (одна из точек во Владивостоке, там не было WAN).
На уровне правил обработки трафика делается фильтрация приложений и потоков. Для пользователей железо Palo Alto забирает права из AD-группы, а для подсистем есть наборы правил — что можно, что нельзя.
На том же железе была сделана «песочница» для контроля того, что качают пользователи или получают через почту. Сначала сигнатурный анализ, потом «песочница», через пару минут письмо приходит конечному пользователю. В офисе и ЦОДе это сделано с дублированием, на кассах — без кластера отказоустойчивости, но с байпассом.
Там же развёрнута (пока простая) защита от DDoS — сигнатуры атак плюс обычный анализатор. При необходимости этот модуль быстро включается и начинает отражать «промышленные» атаки.
Телефония
До начала проекта у заказчика уже была станция на Asterisk. Это прекрасное решение для молодой компании, и настроено оно было просто как часы. Но особенность в том, что Астериск очень тяжело поддерживать, когда компания быстро растёт, а «Аэроэкспресс» рос быстро. В целом это решается компетенциями сисадминов, но тут встаёт вторая задача — распределённость. На момент начала проекта любые проблемы в сети приводили к недоступности телефонов.
Мы внедрили инфраструктуру, главным бизнес-требованием к которой была отказоустойчивость и распределённость. В дата-центре стоит кластер серверов, а на каждом отдельном филиале у заказчика сервера выживаемости.
При отключении филиала от корпоративной сети трафик начинает гоняться внутри филиала через сервер выживаемости. Недоступность в 15 секунд — и все телефоны перерегистрируются на месте. Поднимается SIP-линк, и в город, например в полицию или скорую, позвонить можно. Телефоны работают как обычно, но выпадает продвинутый функционал, предоставляемый центральными серверами (но для аварийного режима более чем достаточно). Итак, основа инфраструктуры — Avaya, подключение к телефонной сети общего пользования по SIP-СЛ и по двухпроводным аналоговым СЛ (локальные подключения к сети РЖД).
Базовая станция AVAYA IP-DECT
В офисе были внедрены дект-трубки мобильные. Базовые станции DECT — это чтобы не гонять трафик через традиционные Wi-Fi-телефоны. Вайфай лучше в разы. Однако с вайфаем очень дорого покупать трубки. Есть дешёвые китайские, но они живут полгода. Нормальные рабочие стоят около тысячи долл. Дектовские же всего около 300 долл.
Опять же, можно было бы, в теории, не делать DECT, а поставить операторские фемтосоты, но нужно было защитить каналы (а фемто не умеет работать во внутрикорпоративном сегменте), установить свои правила и свои фильтры. Плюс заказчику совершенно не нужны были дополнительные договоры с мобильными операторами. Есть PoE для подключения к ЛВС для питания — это чтобы не зависеть от прямых кабельных линий.
Там же из дополнительных плюшек развернули факс-сервер (он реально нужен), UC, в частности, сервис статуса присутствия на рабочем месте — все сотрудники видят занятость линии у контрагентов из кругов общения. Это очень удобно: хочешь позвонить в соседний отдел — и сразу видишь, что нужный человек разговаривает. Положил сотрудник трубку — и сразу набираешь ему.
Итог
Поскольку работы носили плановый характер, а не «у нас проблема, надо срочно», опять же, взаимодействовать было очень приятно. Никакие бизнес-процессы не останавливались, пассажиры никак не заметили, что внутри что-то поменялось, ИТ-служба и кассиры штатно перешли на новую сеть. Заложены места для расширения. Всё тип-топ. В общем, с нашей стороны — просто техническая работа, а со стороны «Аэроэкспресса» — очень грамотная работа ИТ-отдела, планирующего развитие на несколько лет вперёд.
