WireGuard site to site
Last updated
Last updated
Объединение локальных сетей предприятия, расположенных на разных площадках - одна из типовых задач системного администратора, для решения которой могут быть использованы различные инструменты. Выбор туннельных и VPN-протоколов сегодня достаточно обширен: это как "старые-добрые" решения, так и перспективные новички. Один из таких протоколов - WireGuard, сейчас он у всех на слуху и пользуется большой популярностью. В этой статье мы рассмотрим его достоинства и недостатки, а также расскажем, как с его помощью соединить внутренние сети предприятия (site-to-site) и настроить маршрутизацию между ними.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем с того, что WireGuard прост, прост во всем, начиная от архитектуры и заканчивая использованием. Его исходный код содержит всего около 4000 строк. В этом его основное достоинство, ровно, как и недостаток. Еще один несомненный плюс - WireGuard работает как модуль ядра Linux, что позволяет получить высокое быстродействие при минимуме накладных расходов.
Но у простоты есть и обратная сторона, если вы привыкли к обилию возможностей по централизованной передаче настроек клиентам у OpenVPN, либо гибкому выбору наборов шифров в IPsec, то спешим вас огорчить - в WireGuard ничего этого нет. Это просто быстрый и безопасный туннель, не более. В этом плане он больше всего напоминает GRE, только в современном исполнении. А для соединения площадок большего и не надо, в такой схеме все узлы контролируются администратором и настраиваются один раз и надолго, а простота настройки и производительность соединения становятся дополнительными аргументами в пользу WireGuard.
Еще одним плюсом WireGuard, по сравнению с IPsec, является отсутствие необходимости в выделенных IP-адресах на обоих сторонах туннеля для установления защищенного соединения, достаточно одного такого узла.
Во многих руководствах по настройке WireGuard часто используются термины "клиент" и "сервер", однако это не совсем корректно. WireGuard - это туннельный протокол без сохранения состояния (stateless), он создает в системе постоянный сетевой интерфейс, по умолчанию wg0, и обрабатывает трафик на нем в зависимости от указанных правил. Понять в каком состоянии находится канал связи невозможно, для системы интерфейс WireGuard всегда поднят и единственный способ проверить его работоспособность - это отправить пакет на другой конец туннеля. Узел, который устанавливает соединение называется инициатор, узел, который его принимает - респондер.
Установленный экземпляр WireGard может быть и респондером и инициатором одновременно, но чаще всего настраивается схема с одним респондером (сервером) и множеством инициаторов (клиентами). Для работы инициатору не требуется выделенный IP-адрес, и он может находится за NAT.
Далее мы будем рассматривать следующую схему:
Центральный офис имеет внутреннюю сеть 192.168.111.0/24 и выделенный IP-адрес 203.0.113.2, в Филиале внутренняя сеть 192.168.222.0/24, наличие выделенного IP не обязательно. Наша задача - объединить локальные сети площадок при помощи WireGuard. Оба роутера, на которых мы будем разворачивать VPN являются основными шлюзами своих сетей.
WireGuard - новый продукт и его поддержка есть не во всех дистрибутивах, так для Ubuntu это выпуск 18.04 LTS и более поздние, для Debian - начиная с 11 версии, в Debian 10 для поддержки WireGuard необходимо подключить Backports-репозиторий.
Все указанные ниже команды следует выполнять с правами суперпользователя root или через sudo.
Внимание! Данное действие необходимо выполнить только в Debain 10.
Эта команда добавит в источники пакетов адрес Backports-репозитория.
Следующие действия выполняются вне зависимости от используемого дистрибутива.
Обновим источники пакетов и установим WireGuard:
Для поддержки модуля ядра используется DKMS, что позволяет автоматически пересобрать модуль при обновлении ядра, поэтому объем загружаемых и устанавливаемых пакетов может быть довольно значительным.
Сам процесс никаких затруднений вызвать не должен и происходит штатным образом.
Прежде всего создадим ключевую пару, которая будет использоваться для криптографии. Следует помнить, что закрытый ключ является секретным и следует принять меры к его надежному хранению, а также исключить возможность чтения файла другими пользователями. На наш взгляд подходящим местом для хранения ключей будет директория с настройками WireGuard - /etc/wireguard, перейдем в нее:
Для обеспечения правильного набора прав временно изменим маску в системе:
И выполним генерацию ключевой пары:
В результате файлы ключей получат права 0600, что означает доступ только для владельца (т.е. root), после чего не забудем вернуть нормальную маску, для root это 022:
Теперь создадим конфигурационный файл, в WireGuard конфигурационные файлы описывают сетевые интерфейсы и узлы, которые могут через эти интерфейсы работать. Имя файла конфигурации должно совпадать с желаемым именем интерфейса, разработчики предлагают использовать имена wg0 - wgN, но вы можете выбрать любое желаемое имя, например, my-vpn.
Для редактирования будем использовать редактор nano, если вам более по душе редактор mc, то замените в команде nano на mcedit:
И внесем в него следующую секцию, описывающую сетевой интерфейс:
Как мы уже говорили, WireGuard прост, это в полной мере относится и к конфигурации. В целом ее смысл понятен, но все равно поясним назначение параметров. Address - задает желаемый адрес интерфейса в VPN-сети, ListenPort - порт, который слушает WireGuard, какого-либо стандартного порта за сервисом не закреплено, можете использовать любой. При этом помним, что транспортом является протокол UDP. SaveConfig - позволяет автоматически сохранять изменения в конфигурационный файл при управлении службой через CLI. И, наконец, Privatekey - закрытый ключ, его можно найти в одноименном файле или прочитать командой:
Если вам нужно содержимое открытого (публичного) ключа, то измените команду на:
Для того, чтобы WireGuard мог принимать подключения следует разрешить входящие подключения на указанный в конфигурационном файле порт, в нашем случае:
Более подробно о настройках брандмауэра вы можете прочитать в нашей статье: Основы iptables для начинающих. Часть 2. Таблица filter
Ниже должны располагаться секции описывающие подключающиеся узлы - пиры, но так как таковых у нас пока нет, то сохраним конфигурационный файл и переместимся в филиал.
Точно также выполним установку WireGuard и генерацию ключевой пары, эти вопросы описаны выше, и мы не видим смысла повторяться. Перейдем сразу к созданию файла конфигурации:
Первой секцией также будет описание интерфейса:
Здесь она еще более лаконична, так как данный узел будет выступать только в роли инициатора, то мы не указываем порт, тем не менее WireGuard все равно будет слушать входящие подключения, используя для этого случайный порт.
Ниже добавим секцию для связи с центральным офисом, каждый конфигурационный файл WireGuard должен содержать описание всех узлов, с которыми нужно поддерживать связь.
Publickey - это публичный ключ узла на другой стороне туннеля, в данном случае - центрального офиса. Endpoint - адрес и порт респондера, в нашем случае это снова центральный офис. AllowedIPs - адреса или диапазоны сетей, которые имеют право отправлять трафик в туннель. Со стороны центрального офиса это будет 10.10.8.1/32 и сеть 192.168.111.0/24, обратите внимание, что отдельные адреса необходимо указывать с маской /32, при указании иной маски она будет автоматически изменена при запуске службы. В нашем случае вместо отдельного адреса указана вся подсеть 10.10.8.0/24, так как мы считаем ее доверенной и не исключаем появления новых узлов.
Если WireGuard находится за NAT, то могут возникнуть проблемы со стабильностью связи. Это связано с тем, что, как и любой stateless-протокол, WireGuard молчалив, поэтому записи в таблице трансляции NAT могут устаревать и связь со стороны респондера к инициатору будет невозможна до тех пор, пока инициатор не пошлет хотя бы один пакет в туннель. Для избежания такой ситуации добавьте в секцию Peer нужного узла дополнительную опцию:
Которая заставит раз в 25 секунд посылать на другой конец туннеля служебный пакет, тем самым поддерживая данные в таблице трансляции актуальными.
Сохраним конфигурационный файл и добавим службу в автозагрузку, WireGuard предусматривает для каждого интерфейса запуск отдельной службы, что удобно:
Опция --now предписывает сразу запустить службу, в качестве ее имени указываем wg-quick@<имя_конфигурационного_файла>.
Теперь можем посмотреть ее состояние командой:
Внимательное изучение вывода команды покажет, что WireGuard автоматически добавил маршрут к сети центрального офиса, которую мы указали в опции AllowedIPs, чтобы убедиться в этом выполним еще одну команду:
Да, маршрут действительно добавлен, что избавляет администратора от дополнительной ручной работы.
Также обратите внимание, что интерфейс wg0 успешно поднялся несмотря на то, что в центральном офисе служба WireGuard до сих пор не запущена. Это характерная особенность всех протоколов без сохранения состояния, однако это упрощает поведение и не требует дополнительных мер по отслеживанию состояния канала и переподключению.
Каких-либо настроек брандмауэра в филиале выполнять не нужно.
Вернемся в центральный офис, теперь у нас появился первый узел, и мы можем закончить настройку. Снова откроем конфигурационный файл wg0.conf и добавим в него секцию Peer следующего содержания.
Здесь все еще более лаконично, в опции Publickey указываем публичный ключ филиала, а в AllowedIPs указываем адрес интерфейса филиала и сеть за ним.
Добавляем интерфейс в автозагрузку и запускаем его:
Точно также в таблицу маршрутизации будет добавлен маршрут к сети за роутером филиала, а интерфейс будет поднят вне зависимости от реального состояния канала связи.
Попробуем проверить связь, для этого просто пропингуем внутренний адрес филиала 10.10.8.101 и затем посмотрим состояние WireGuard командой:
Данная команда выводит достаточный минимум об интерфейсах и пирах, включая их публичные ключи, а также статистику соединений.
В заключение проверим связь между узлами сетей:
Если вы нигде не допустили ошибок - связь между узлами сетей будет.
Как видим, настроить VPN между офисами при помощи WireGuard очень просто, получив кроме простоты использования высокую производительность данного решения на платформе Linux.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
