# WireGuard site to site ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-07a19970481092c55d30f451130f28a791839c83%2Fwireguard-site-to-site-000.png?alt=media) Объединение локальных сетей предприятия, расположенных на разных площадках - одна из типовых задач системного администратора, для решения которой могут быть использованы различные инструменты. Выбор туннельных и VPN-протоколов сегодня достаточно обширен: это как "старые-добрые" решения, так и перспективные новички. Один из таких протоколов - WireGuard, сейчас он у всех на слуху и пользуется большой популярностью. В этой статье мы рассмотрим его достоинства и недостатки, а также расскажем, как с его помощью соединить внутренние сети предприятия (site-to-site) и настроить маршрутизацию между ними. Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на [углубленном курсе по администрированию MikroTik](https://xn-----xlcfvffioc4g.xn--p1ai/lp-mikrotik-mtcna?utm_source=interface31\&utm_medium=cpc\&utm_campaign=2-1368). Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда. Начнем с того, что WireGuard прост, прост во всем, начиная от архитектуры и заканчивая использованием. Его исходный код содержит всего около 4000 строк. В этом его основное достоинство, ровно, как и недостаток. Еще один несомненный плюс - WireGuard работает как модуль ядра Linux, что позволяет получить высокое быстродействие при минимуме накладных расходов. Но у простоты есть и обратная сторона, если вы привыкли к обилию возможностей по централизованной передаче настроек клиентам у OpenVPN, либо гибкому выбору наборов шифров в IPsec, то спешим вас огорчить - в WireGuard ничего этого нет. Это просто быстрый и безопасный туннель, не более. В этом плане он больше всего напоминает GRE, только в современном исполнении. А для соединения площадок большего и не надо, в такой схеме все узлы контролируются администратором и настраиваются один раз и надолго, а простота настройки и производительность соединения становятся дополнительными аргументами в пользу WireGuard. Еще одним плюсом WireGuard, по сравнению с IPsec, является отсутствие необходимости в выделенных IP-адресах на обоих сторонах туннеля для установления защищенного соединения, достаточно одного такого узла. Во многих руководствах по настройке WireGuard часто используются термины "клиент" и "сервер", однако это не совсем корректно. WireGuard - это туннельный протокол без сохранения состояния (**stateless**), он создает в системе постоянный сетевой интерфейс, по умолчанию **wg0**, и обрабатывает трафик на нем в зависимости от указанных правил. Понять в каком состоянии находится канал связи невозможно, для системы интерфейс WireGuard всегда поднят и единственный способ проверить его работоспособность - это отправить пакет на другой конец туннеля. Узел, который устанавливает соединение называется **инициатор**, узел, который его принимает - **респондер**. Установленный экземпляр WireGard может быть и респондером и инициатором одновременно, но чаще всего настраивается схема с одним респондером (сервером) и множеством инициаторов (клиентами). Для работы инициатору не требуется выделенный IP-адрес, и он может находится за NAT. Далее мы будем рассматривать следующую схему: ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-e2ec77168b15b5c891d89d8c84fd4e94cd5895d7%2Fwireguard-site-to-site-001-thumb-600xauto-14332.png?alt=media) **Центральный офис** имеет внутреннюю сеть **192.168.111.0/24** и выделенный IP-адрес **203.0.113.2**, в **Филиале** внутренняя сеть **192.168.222.0/24**, наличие выделенного IP не обязательно. Наша задача - объединить локальные сети площадок при помощи WireGuard. Оба роутера, на которых мы будем разворачивать VPN являются основными шлюзами своих сетей. ### Установка WireGuard в Debian и Ubuntu WireGuard - новый продукт и его поддержка есть не во всех дистрибутивах, так для Ubuntu это выпуск 18.04 LTS и более поздние, для Debian - начиная с 11 версии, в Debian 10 для поддержки WireGuard необходимо подключить Backports-репозиторий. Все указанные ниже команды следует выполнять с правами суперпользователя root или через sudo. Внимание! Данное действие необходимо выполнить только в Debain 10. ``` echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/buster-backports.list ``` Эта команда добавит в источники пакетов адрес Backports-репозитория. Следующие действия выполняются вне зависимости от используемого дистрибутива. Обновим источники пакетов и установим WireGuard: ``` apt update apt install wireguard ``` Для поддержки модуля ядра используется DKMS, что позволяет автоматически пересобрать модуль при обновлении ядра, поэтому объем загружаемых и устанавливаемых пакетов может быть довольно значительным. Сам процесс никаких затруднений вызвать не должен и происходит штатным образом. ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-c2888549732299fd9ab5188d2c12f9bb4ccf3c74%2Fwireguard-site-to-site-002-thumb-600xauto-14335.png?alt=media) ### Настройка WireGuard в центральном офисе (начало) Прежде всего создадим ключевую пару, которая будет использоваться для криптографии. Следует помнить, что закрытый ключ является секретным и следует принять меры к его надежному хранению, а также исключить возможность чтения файла другими пользователями. На наш взгляд подходящим местом для хранения ключей будет директория с настройками WireGuard - **/etc/wireguard**, перейдем в нее: ``` cd /etc/wireguard ``` Для обеспечения правильного набора прав временно изменим маску в системе: ``` umask 077 ``` И выполним генерацию ключевой пары: ``` wg genkey > privatekey wg pubkey < privatekey > publickey ``` В результате файлы ключей получат права 0600, что означает доступ только для владельца (т.е. root), после чего не забудем вернуть нормальную маску, для **root** это 022: ``` umask 022 ``` ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-3d98eb9f8f3530b6f4ab00e432c36ab4e147ecfd%2Fwireguard-site-to-site-003.png?alt=media) Теперь создадим конфигурационный файл, в WireGuard конфигурационные файлы описывают сетевые интерфейсы и узлы, которые могут через эти интерфейсы работать. Имя файла конфигурации должно совпадать с желаемым именем интерфейса, разработчики предлагают использовать имена **wg0 - wgN**, но вы можете выбрать любое желаемое имя, например, **my-vpn**. Для редактирования будем использовать редактор nano, если вам более по душе редактор mc, то замените в команде **nano** на **mcedit**: ``` nano /etc/wireguard/wg0.conf ``` И внесем в него следующую секцию, описывающую сетевой интерфейс: ``` [Interface] Address = 10.10.8.1/24 SaveConfig = true ListenPort = 34567 Privatekey = kNYGiCR3/ikepyURjFnEu5ueoCBsP2pjvGdcj2pggG8= ``` Как мы уже говорили, WireGuard прост, это в полной мере относится и к конфигурации. В целом ее смысл понятен, но все равно поясним назначение параметров. **Address** - задает желаемый адрес интерфейса в VPN-сети, **ListenPort** - порт, который слушает WireGuard, какого-либо стандартного порта за сервисом не закреплено, можете использовать любой. При этом помним, что транспортом является протокол UDP. **SaveConfig** - позволяет автоматически сохранять изменения в конфигурационный файл при управлении службой через CLI. И, наконец, **Privatekey** - закрытый ключ, его можно найти в одноименном файле или прочитать командой: ``` cat /etc/wireguard/privatekey ``` Если вам нужно содержимое открытого (публичного) ключа, то измените команду на: ``` cat /etc/wireguard/publickey ``` Для того, чтобы WireGuard мог принимать подключения следует разрешить входящие подключения на указанный в конфигурационном файле порт, в нашем случае: ``` iptables -A INPUT -p udp --dport 34567 -j ACCEPT ``` Более подробно о настройках брандмауэра вы можете прочитать в нашей статье: [Основы iptables для начинающих. Часть 2. Таблица filter](https://interface31.ru/tech_it/2020/09/osnovy-iptables-dlya-nachinayushhih-chast-2-tablica-filter.html) Ниже должны располагаться секции описывающие подключающиеся узлы - пиры, но так как таковых у нас пока нет, то сохраним конфигурационный файл и переместимся в филиал. ### Настройка WireGuard в филиале Точно также выполним установку WireGuard и генерацию ключевой пары, эти вопросы описаны выше, и мы не видим смысла повторяться. Перейдем сразу к созданию файла конфигурации: ``` nano /etc/wireguard/wg0.conf ``` Первой секцией также будет описание интерфейса: ``` [Interface] Address = 10.10.8.101/24 SaveConfig = true Privatekey = 4Hfj7lZuaQZWkW2OGHPlkhr3Jxheg/lpcJkwiosvG0w= ``` Здесь она еще более лаконична, так как данный узел будет выступать только в роли инициатора, то мы не указываем порт, тем не менее WireGuard все равно будет слушать входящие подключения, используя для этого случайный порт. Ниже добавим секцию для связи с центральным офисом, каждый конфигурационный файл WireGuard должен содержать описание всех узлов, с которыми нужно поддерживать связь. ``` [Peer] Publickey = BgUTtDHbxU+8fQU+wntddvE2f8YYcskPU/FVNfwBy2Q= Endpoint = 203.0.113.2:34567 AllowedIPs = 10.10.8.0/24, 192.168.111.0/24 ``` **Publickey** - это публичный ключ узла на другой стороне туннеля, в данном случае - **центрального офиса**. **Endpoint** - адрес и порт респондера, в нашем случае это снова центральный офис. **AllowedIPs** - адреса или диапазоны сетей, которые имеют право отправлять трафик в туннель. Со стороны центрального офиса это будет **10.10.8.1/32** и сеть **192.168.111.0/24**, обратите внимание, что отдельные адреса необходимо указывать с маской **/32**, при указании иной маски она будет автоматически изменена при запуске службы. В нашем случае вместо отдельного адреса указана вся подсеть **10.10.8.0/24**, так как мы считаем ее доверенной и не исключаем появления новых узлов. ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-7a057adc2659a4fc904c1f8f11047656485e320a%2Fwireguard-site-to-site-004-thumb-600xauto-14339.png?alt=media) Если WireGuard находится за NAT, то могут возникнуть проблемы со стабильностью связи. Это связано с тем, что, как и любой stateless-протокол, WireGuard молчалив, поэтому записи в таблице трансляции NAT могут устаревать и связь со стороны респондера к инициатору будет невозможна до тех пор, пока инициатор не пошлет хотя бы один пакет в туннель. Для избежания такой ситуации добавьте в секцию **Peer** нужного узла дополнительную опцию: ``` PersistentKeepalive = 25 ``` Которая заставит раз в 25 секунд посылать на другой конец туннеля служебный пакет, тем самым поддерживая данные в таблице трансляции актуальными. Сохраним конфигурационный файл и добавим службу в автозагрузку, WireGuard предусматривает для каждого интерфейса запуск отдельной службы, что удобно: ``` systemctl enable --now wg-quick@wg0 ``` Опция **--now** предписывает сразу запустить службу, в качестве ее имени указываем **wg-quick@<имя\_конфигурационного\_файла>**. Теперь можем посмотреть ее состояние командой: ``` systemctl status wg-quick@wg0 ``` ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-7d0d6a69b1159ccd24fce96684fa08181351816e%2Fwireguard-site-to-site-005-thumb-600xauto-14342.png?alt=media) Внимательное изучение вывода команды покажет, что WireGuard автоматически добавил маршрут к сети центрального офиса, которую мы указали в опции **AllowedIPs**, чтобы убедиться в этом выполним еще одну команду: ``` ip r ``` Да, маршрут действительно добавлен, что избавляет администратора от дополнительной ручной работы. ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-8af9a07b31ec46717ee0ba16976dae6a2928673a%2Fwireguard-site-to-site-006-thumb-600xauto-14345.png?alt=media) Также обратите внимание, что интерфейс **wg0** успешно поднялся несмотря на то, что в центральном офисе служба WireGuard до сих пор не запущена. Это характерная особенность всех протоколов без сохранения состояния, однако это упрощает поведение и не требует дополнительных мер по отслеживанию состояния канала и переподключению. Каких-либо настроек брандмауэра в филиале выполнять не нужно. ### Настройка WireGuard в центральном офисе (окончание) Вернемся в центральный офис, теперь у нас появился первый узел, и мы можем закончить настройку. Снова откроем конфигурационный файл **wg0.conf** и добавим в него секцию **Peer** следующего содержания. ``` [Peer] Publickey = MOsT/LECNPA0FqOONJEhqZWqqwOV+lYsnQNLaUkrvFI= AllowedIPs = 10.10.8.101/32, 192.168.222.0/24 ``` Здесь все еще более лаконично, в опции **Publickey** указываем **публичный ключ филиала**, а в **AllowedIPs** указываем адрес интерфейса филиала и сеть за ним. Добавляем интерфейс в автозагрузку и запускаем его: ``` systemctl enable --now wg-quick@wg0 ``` Точно также в таблицу маршрутизации будет добавлен маршрут к сети за роутером филиала, а интерфейс будет поднят вне зависимости от реального состояния канала связи. Попробуем проверить связь, для этого просто пропингуем внутренний адрес филиала **10.10.8.101** и затем посмотрим состояние WireGuard командой: ``` wg ``` ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-68a19f06a0fe67cbc2a206e8654059db149ca047%2Fwireguard-site-to-site-007-thumb-600xauto-14348.png?alt=media) Данная команда выводит достаточный минимум об интерфейсах и пирах, включая их публичные ключи, а также статистику соединений. В заключение проверим связь между узлами сетей: Если вы нигде не допустили ошибок - связь между узлами сетей будет. ![](https://296194292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLoAqAoOfr7XVUQw7Gff8%2Fuploads%2Fgit-blob-8c28268adc3a143e74995e50108bce52796c670f%2Fwireguard-site-to-site-008-thumb-600xauto-14351.png?alt=media) Как видим, настроить VPN между офисами при помощи WireGuard очень просто, получив кроме простоты использования высокую производительность данного решения на платформе Linux. Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на [углубленном курсе по администрированию MikroTik](https://xn-----xlcfvffioc4g.xn--p1ai/lp-mikrotik-mtcna?utm_source=interface31\&utm_medium=cpc\&utm_campaign=2-1368). Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.