Как только части одной системы оказываются у разных провайдеров, между ними требуется закрытый контур: базы данных не должны быть доступны из открытого интернета, а обмен между площадками обязан шифроваться. Классические решения для таких сетей тяжелы в настройке и капризны в сопровождении, а WireGuard переворачивает картину: несколько тысяч строк кода в ядре системы, современная криптография и конфигурация на пару десятков строк. Разберём построение защищённой сети между облаками: ключи, маршрутизацию подсетей, прохождение через преобразование адресов и схему отказоустойчивости, когда связь между площадками переживает отказ любого узла.
Чем туннель WireGuard выигрывает у классических решений
Первое отличие это место в системе: WireGuard работает в пространстве ядра, а не в отдельной программе пользовательского режима, поэтому скорость шифрования близка к возможностям процессора, и задержки минимальны. Второе отличие это размер и читаемость: кодовая база в разы меньше классических решений, и обозреть её целиком по силам одному специалисту, что напрямую отражается на доверии к безопасности. Третье это молчаливость протокола: узел не отвечает на запросы, если у него нет правильных ключей, и поверхность, видимая сканерам из интернета, практически пуста.
Криптографический набор выбран за нас и зафиксирован жёстко: обмен ключами на кривых, шифрование потоковыми шифрами, проверка целостности в том же слое. Отсутствие выбора алгоритмов звучит как ограничение, но работает как достоинство: нет неверных комбинаций настроек, нет переговоров о слабых вариантах, есть одна проверенная схема. Доверие между узлами строится на публичных ключах, и вся инфраструктура удостоверяющих центров для закрытой сети из нескольких площадок попросту не нужна.
Ключи и базовая настройка узла туннеля
На каждом узле создаётся пара ключей, приватный остаётся на месте, публичные обмениваются любым удобным каналом. Генерация занимает одну строку, и правильной привычкой является установка строгих прав на файлы ключей сразу после создания:
wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekeyКонфигурация узла описывает интерфейс, адрес в закрытой сети и список узлов партнёров с их публичными ключами и разрешёнными адресами. Файл кладётся в каталог настроек туннелей, и служба управления поднимает интерфейс одной командой:
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <приватный ключ этого узла>
[Peer]
PublicKey = <публичный ключ партнёра>
AllowedIPs = 10.10.0.2/32, 10.1.0.0/16
PersistentKeepalive = 25Поле разрешённых адресов работает двойно: оно определяет, какой трафик шифруется в туннель к этому партнёру, и одновременно служит фильтром входящего, поэтому адреса закрытой сети стоит распланировать заранее и не допускать пересечений между площадками. Служба включается в автозапуск, и после подъёма интерфейса узлы обмениваются ключами при первом же пакете.
Соединение двух облаков и маршрутизация подсетей
Для связки двух площадок каждая машина узла должна разрешать пересылку пакетов между интерфейсами, иначе туннель поднимется, а трафик между подсетями не пойдёт. Пересылка включается параметром ядра, и правило стоит сделать постоянным через файл настроек системы:
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.d/99-forward.confДальше проектируется адресный план. Пусть первая площадка живёт в диапазоне с октетом десять на первом месте, вторая с октетом одиннадцать, а адреса туннельных интерфейсов берутся из отдельного малого диапазона. Каждый узел в разрешённых адресах партнёра перечисляет его подсеть целиком, и тогда любая машина первой площадки достигает любой машины второй через узел туннеля. Обратная сторона маршрутизации это возвратный трафик: машины с обычными адресами отправляют ответы через свой основной шлюз, поэтому на узлах туннеля добавляют правило подмены источника, либо прописывают маршруты на уровне каждой машины. Правильнее всего завести маршруты в настройках сети площадки, если провайдер позволяет описывать их декларативно.
Машины первого облака видят второй через узел, и наоборот, и закрытая сеть начинает работать как единое целое. Ничто при этом не мешает оставить базы данных слушающими только частные адреса: доступ к ним возможен исключительно через туннель, и публичная поверхность площадок остаётся минимальной.
Сетка из трёх и более провайдеров и роли узлов
Как только площадок становится три, возникает выбор топологии. Полная сетка, где каждый узел связан с каждым, проста в понимании и не имеет единых точек отказа, но число связей растёт квадратично, и при пяти площадках планирование начинает требовать дисциплины. Звезда с центральным узлом экономит связи, но центр становится узким местом по трафику и точкой отказа. Практичная середина выглядит так: площадки соединяются попарно по необходимости трафика, а отдельный резервный узел у независимого третьего провайдера служит запасным транзитом.
Роли узлов при этом раздаются явно. Узел площадка получает подсеть своей площадки в разрешённые адреса и обязан пересылать пакеты. Узел транзит держит маршруты ко всем подсетям и разрешённые адреса шире. Такой явный словарь ролей, записанный в документацию рядом с адресным планом, избавляет от ситуации, через которую проходят все растущие закрытые сети: найти через полгода, что один из узлов настроен вручную в спешке, и никто не помнит деталей.
Преобразование адресов, поддержание связи и отказоустойчивость
Облачные машины обычно стоят за преобразованием адресов, и входящее соединение к ним извне требует проброса порта. Схема с одним общим узлом устроена просто: у узла, стоящего за преобразованием, прописывается постоянное поддержание связи, и он сам держит отверстие открытым исходящими пакетами каждые двадцать пять секунд. Тогда встречная сторона может находиться где угодно, а соединение устанавливается в сторону того, у кого адрес стабильный.
Правило проектирования звучит так: стабильный адрес должен быть хотя бы у одной из сторон каждой связи, и именно к ней прокладывается открытое правило брандмауэра для протокола туннеля. Если обе стороны сидят за преобразованием адресов и проброс невозможен, между ними ставится узел ретрансляции со стабильным адресом, и обе стороны связываются через него. Это добавляет один прыжок задержки, зато снимает зависимость от провайдерских панелей пробросов, которые не везде доступны.
Проверка связи после настройки выглядит одинаково на всех узлах: утилита состояния показывает обмен ключами и последнее рукопожатие с каждым партнёром. Если рукопожатие не состоялось, причины почти всегда в трёх местах: не открыт порт протокола на пути, ключи перепутаны между узлами, разрешённые адреса не покрывают проверяемый диапазон.
Связь между двумя площадками через один туннель уязвима к отказу любого из двух узлов, и отказоустойчивость строится на втором пути. Классическая схема это резервный узел у третьего провайдера с двумя туннелями: к первой и второй площадкам. Наблюдение на каждой площадке проверяет доступность чужой подсети через основной путь и, потеряв её, направляет трафик через резервный узел, а восстановив, возвращает обратно. Приоритеты маршрутов задаются метриками, и переключение происходит без участия человека за секунды.
Глубина проверки важнее самой проверки: датчик должен проверять не интерфейс туннеля, а реальную достижимость машины в чужой подсети, например обращение к заведомо поднятому порту на проверочном узле. Иначе туннель считается живым при мёртвой маршрутизации на чужой стороне, и переключение не происходит. Тот же датчик отправляет оповещение о каждом переключении: молчаливое резервирование красиво в теории, но хозяйство должно знать, что работает по запасному пути, и почему.
Состояние ключей при переключении не требует никакой синхронизации: резервный узел имеет свои пары ключей и прописанных партнёров, и схема не зависит от общего хранилища секретов. Это упрощает аудит: скомпрометация ключа одного узла не требует ротации всей сети, достаточно перевыпустить ключ на этом узле и обновить его у партнёров.
Производительность туннеля и связка с защитой площадок
Работа в пространстве ядра даёт туннелю скорость, достаточную для большинства связок между площадками: узкое место почти всегда находится в канале провайдера, а не в шифровании. Тем не менее при переносе больших выгрузок между площадками стоит убедиться, что канал между облаками достаточно широк, и что узлы туннеля не сидят на минимальных типах машин с одним скромным ядром.
Единственная настройка, которую стоит понимать глубже, это размер передаваемых пакетов. Шифрование добавляет служебные байты к каждому пакету, и если внутренний размер оставлен по умолчанию на путях с собственными служебными заголовками, большие пакеты начинают дробиться, что снижает скорость и порождает трудноуловимые сбои отдельных служб. Рабочее значение для туннеля поверх обычных каналов обычно на двадцать байт меньше стандартного, и его задают в настройках интерфейса. Проверка выполняется отправкой непременно полного пакета между площадками: если дробление есть, оно проявится сразу.
Для тяжёлых потоков стоит также помнить о процессорных возможностях узлов: шифрование на современном железе почти бесплатно благодаря аппаратным инструкциям, но минимальные машины с разделяемыми ядрами могут показать скромную полосу именно на узлах туннеля. В таком случае узел туннеля выносят на тип машины с выделенным ядром, и полоса вырастает без изменения конфигурации.
Туннель сам по себе не делает сеть защищённой, он лишь открывает закрытый путь. Дальше работает дисциплина брандмауэров: базы данных на каждой площадке слушают только частные адреса, и правила допускают обращения к ним исключительно из диапазонов чужих подсетей через туннель. Административный доступ к машинам likewise закрывается от открытого интернета и оставляется через туннель или через средства управления площадкой.
Правила разрешённых адресов в конфигурации туннеля дополняют картину: узел примет зашифрованные пакеты только с адресов, перечисленных в поле партнёра, и подделка адреса внутри туннеля отсекается на входе. Так защита собирается в глубину: открытый интернет видит только порт туннеля на стабильных узлах, туннель видит только ключевые пары, а брандмауэры площадок видят только диапазоны закрытой сети.
Отдельная привычка это изоляция сред. Тестовые машины живут в собственных подсетях, их диапазоны перечислены в разрешённых адресах на отдельных узлах, и компрометация тестового узла не открывает путь в боевой контур. Когда подсети разнесены и правила сформулированы диапазонами, а не отдельными машинами, такая изоляция достаётся бесплатно.
Проверка связи и сопровождение ключей
Эксплуатация закрытой сети сводится к нескольким привычкам. Регулярный просмотр состояний узлов показывает свежесть рукопожатий и объём переданного: застывшие счётчики сигналят о лежащем пути раньше пользователей. Проверка достижимости подсетей из разных точек вешается на систему мониторинга как отдельная проверка, отдельная от проверки самих машин, потому что маршрут и машина ломаются по разным причинам.
Сопровождение ключей устроено просто, если завести на него порядок: список узлов с датами создания ключей и местом их применения, ротация по расписанию или по событию, и правило никогда не копировать приватный ключ с машины на машину. Добавление новой площадки тогда занимает четверть часа: пара ключей, конфигурация узла, запись партнёров на существующих узлах, запись в адресный план. Сеть из разнородных облаков при этом остаётся тем, чем задумывалась: единым закрытым контуром, который переживает отказы отдельных площадок и провайдеров и не зависит от прихотей ни одного из них. Именно за это сочетание простоты и устойчивости закрытые сети на WireGuard и стали рабочим стандартом для хозяйств из нескольких площадок.