# WireGuard site to site ![](/files/Aq9Jdm2BJwUVdNY4BnCQ) Объединение локальных сетей предприятия, расположенных на разных площадках - одна из типовых задач системного администратора, для решения которой могут быть использованы различные инструменты. Выбор туннельных и 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. Далее мы будем рассматривать следующую схему: ![](/files/nGnoNQv8EOQTa1he5IdR) **Центральный офис** имеет внутреннюю сеть **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, что позволяет автоматически пересобрать модуль при обновлении ядра, поэтому объем загружаемых и устанавливаемых пакетов может быть довольно значительным. Сам процесс никаких затруднений вызвать не должен и происходит штатным образом. ![](/files/MtgchWUidqUCJe5MfagQ) ### Настройка WireGuard в центральном офисе (начало) Прежде всего создадим ключевую пару, которая будет использоваться для криптографии. Следует помнить, что закрытый ключ является секретным и следует принять меры к его надежному хранению, а также исключить возможность чтения файла другими пользователями. На наш взгляд подходящим местом для хранения ключей будет директория с настройками WireGuard - **/etc/wireguard**, перейдем в нее: ``` cd /etc/wireguard ``` Для обеспечения правильного набора прав временно изменим маску в системе: ``` umask 077 ``` И выполним генерацию ключевой пары: ``` wg genkey > privatekey wg pubkey < privatekey > publickey ``` В результате файлы ключей получат права 0600, что означает доступ только для владельца (т.е. root), после чего не забудем вернуть нормальную маску, для **root** это 022: ``` umask 022 ``` ![](/files/kxHTqDNvQaTA3TnXONNt) Теперь создадим конфигурационный файл, в 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**, так как мы считаем ее доверенной и не исключаем появления новых узлов. ![](/files/fmShIgXgBVIbCWPm21ja) Если WireGuard находится за NAT, то могут возникнуть проблемы со стабильностью связи. Это связано с тем, что, как и любой stateless-протокол, WireGuard молчалив, поэтому записи в таблице трансляции NAT могут устаревать и связь со стороны респондера к инициатору будет невозможна до тех пор, пока инициатор не пошлет хотя бы один пакет в туннель. Для избежания такой ситуации добавьте в секцию **Peer** нужного узла дополнительную опцию: ``` PersistentKeepalive = 25 ``` Которая заставит раз в 25 секунд посылать на другой конец туннеля служебный пакет, тем самым поддерживая данные в таблице трансляции актуальными. Сохраним конфигурационный файл и добавим службу в автозагрузку, WireGuard предусматривает для каждого интерфейса запуск отдельной службы, что удобно: ``` systemctl enable --now wg-quick@wg0 ``` Опция **--now** предписывает сразу запустить службу, в качестве ее имени указываем **wg-quick@<имя\_конфигурационного\_файла>**. Теперь можем посмотреть ее состояние командой: ``` systemctl status wg-quick@wg0 ``` ![](/files/ZB1i126A0Q7VSFpwiZSI) Внимательное изучение вывода команды покажет, что WireGuard автоматически добавил маршрут к сети центрального офиса, которую мы указали в опции **AllowedIPs**, чтобы убедиться в этом выполним еще одну команду: ``` ip r ``` Да, маршрут действительно добавлен, что избавляет администратора от дополнительной ручной работы. ![](/files/cU971Z0gippFI6Q6t5O0) Также обратите внимание, что интерфейс **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 ``` ![](/files/Ckcx3ehiqc0nr6doJpCL) Данная команда выводит достаточный минимум об интерфейсах и пирах, включая их публичные ключи, а также статистику соединений. В заключение проверим связь между узлами сетей: Если вы нигде не допустили ошибок - связь между узлами сетей будет. ![](/files/6X6PhV5INwXaEoWoZKXw) Как видим, настроить 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 часов практики и доступ навсегда. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.konstantinsecurity.com/readme/architect/vpn/wireguard/wireguard-site-to-site.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.