Как настроить wireguard на keenetic

Доступ в локальную сеть и в интернет через Wireguard для Keenetic

Настройка Wireguard для Keenetic для одновременного доступа в локальную сеть и в интернет через VPN.

В данной заметке я расскажу, как организовать соединение с вашей локальной сетью за роутером Keenetic, если у вас уже настроен выход в интернет через WG сервер с роутера и телефона.

Использование VPN сегодня это такая же необходимость, как установка сложных уникальных паролей и двухфакторная авторизация. Для меня отсутствие VPN — это как уйти из дома и не закрыть на ключ дверь.

Помимо защиты ваших интернет соединений VPN может обеспечить соединение с вашей домашней сетью. Таким образом я организую свое небольшое облако. Файлы из моей домашней сети всегда доступны, где бы я не был.

Как я уже говорил у вас уже должен быть настроен Wireguard сервер, роутер и телефон должны выходить через этот сервер в интернет. Я же расскажу, как с телефона попасть в локальную сеть за роутером с использованием Wireguard, и при этом не потерять VPN выход в интернет. Для этого нужно будет использовать консоль роутера Keenetic.

Настройка Keenetic

Если доступа в консоль нет, то его надо включить. Для этого перейдите в раздел “Управление” -> “Пользователи и доступ”. Проверьте что установлен порт управления по SSH и активирован пункт “Подключения к командной строке по SSH”.

Также убедитесь, что у вас есть пользователь, у которого есть права входа через SSH. На той же странице у вас есть список пользователей. Зайдите в редактор прав пользователя, и убедитесь что у него активирован пункт “Доступ к командной строке (TELNET и SSH)”.

Теперь заходим в консоль управления роутером.

Первым делом нам надо узнать, какой интерфейс был присвоен нашему соединению на роутере. Если это ваше первое соединение с Wireguard, то скорее всего это Wireguard0. Но давайте убедимся в этом.

Для этого необходимо ввести interface Wire и нажать Tab :

Чтобы точно убедиться выведите информацию об интерфейса.

По названию и адресу понимаем, что это нужное соединение.

Нужно добавить правило на IN, иначе запросы в локальную сеть будут дропаться. Не забудьте заменить Wireguard0 на другое значение, если у вас задействован другой интерфейс.

Теперь надо добавить статический маршрут до сети Wireguard.

Настройка сервера WG

Теперь нужно настроить сервер Wireguard. Для этого нужно отредактировать файл конфигурации, обычно он лежит в папке /etc/wireguard/wg0.conf . Зайдите под root.

У нас тут все стандартно. Два пира, один из них роутер, второй телефон. Для роутера необходимо указать в AllowedIPs вашу локальную сеть, в данном случае 192.168.1.0/24 .

После этого отключим и включим WG соединение.

После этого у вас должен появится доступ к локальной сети роутера с телефона через Wireguard VPN. По аналогии можно настроить доступ к локальной сети для остальных устройств.

Универсальный VPN с WireGuard, MikroTik и Keenetic

В данной статье я поделюсь опытом и конфигами для построения универсального семейного VPN — как для конечных потребителей, так и для организации сетевого взаимодействия между дачей и квартирой.

настроить на VPS сервере WireGuard

организовать связь через WireGuard между двумя домашними сетями без публичных IP

организовать выход с клиентских устройств в интернет без границ, если ваш VPS находится на иностранной площадке

WG

Конечно, разных статей про WG много — тем не менее, когда мне понадобилось решить комплексную задачу, те статьи, которые я находил, мне не помогали. Рискну предположить, что так происходило потому, что в большинстве статей приводится рецепт без объяснения механики происходящего, поэтому шаг влево или вправо делает инструкцию бесполезной. Я хочу ликвидировать этот пробел и дать читателю в руки не только инструкцию, но и понимание, как это работает, чтобы он имел возможность реализовать что-то из того, что нигде не описано.

Для начала опишу задачу, которая у меня возникла и которая была успешно решена. Исходной отправной точкой была идея связать два сетевых сегмента — на даче и в квартире, чтобы можно было админить одну сетку из другой и наоборот. Так сложилось, что среда оказалась гетерогенной — дома стоит роутер Keenetic Viva, доступ к его админке есть из интернета благодаря технологиям Keenetic, а вот на даче стоит MirkoTik RB3011, и у местного провайдера нет услуг типа публичного IP. Идея витала давно, но драйвером реализации стало то, что классный VPN Windscribe перестал работать через моего провайдера совсем. Я решил арендовать VPS за рубежом, настроить VPN для членов семьи, и заодно связать две сетки — как вишенка на торте. Целевая архитектура выглядит так:

Был арендован VPS сервер у провайдера Fornex _{[ссылка удалена модератором]} , в качестве отправной статьи для настройки WireGuard была использована статья на 1cloud. Далее идём по порядку — я использовал рутовый аккаунт, поэтому команды без sudo .

Переходим в каталог /etc/wireguard и все всё делаем там. Пока всё согласно инструкции — генерим ключевую пару для сервера:

В результате у нас появятся два ключа — закрытый и публичный, они будут использоваться для подключений к WG серверу. Теперь пришло время вернуться к изучению матчасти — как работает WG, какими сущностями оперирует и к чему это всё приводит. Упрощённо схема работы WG выглядит так:

Данная схема описывает следующие факты и соображения:

В результате запуска WG сервера поднимается отдельный сетевой интерфейс на хосте.

Конфигурация WG сервера применяется к сетевому интерфейсу.

Для каждого клиентского соединения на стороне сервера настраивается свой peer, он же пир.

Защищённый канал устанавливается между двумя пирами.

Сервер не настраивает параметры клиентских пиров, он настраивает только свои пиры.

Пир, он же peer, как следует из перевода термина, является равноправным участником обмена данными, пиры на сервере не отличаются по правам от пиров на клиентах, и каждый пир имеет свои собственные настройки, и данные настройки определяют, какие данные будут отправлены в защищённый канал, и это очень важный факт, который поможет настроить параметры для решения задачи.

Сначала разберём поток пакетов из квартирной сети в сеть дачи и обратно. Предположим, что у нас есть следующие параметры:

подсеть квартиры, Keenetic

подсеть дачи, MikroTik

Касательно подсети VPN — можно задать любую подсеть из числа внутренних, непубличных адресов. Я у себя выбрал такую, у вас может быть любая, соответствующая критерию внутренней.

Пойдём по шагам.

Настроить сервер WG для приёма подключений клиентских пиров.

Настроить в Keenetic передачу пакетов в соединение VPN.

Настроить клиентский пир WG на Keenetic, чтобы всё, что приходит на этот пир, отправлялось в канал WG.

Настроить серверный пир WG для Keenetic, чтобы всё, что приходит из сети 192.168.0.0/24 в канал WG, отправлялось в сеть 192.168.88.0/24.

Настроить клиентский пир WG на MiroTik, чтобы всё, что приходит на этот пир, отправлялось в канал WG.

Настроить серверный пир WG Mikrotik, чтобы всё, что приходит из сети 192.168.88.0/24 в канал WG, отправлялось в сеть 192.168.0.0/24.

Начнём с настройки сервера WG, для этого нам понадобится ключ, сформированный ранее в /etc/wireguard с именем privatekey .

Для начала настроим интерконнект между двумя сетями — квартира и дача. Прежде, чем это сделать, надо сгенерировать ключевые пары для пиров квартиры и дачи, т.е. для их роутеров:

Сформируем файл в каталоге /etc/wireguard с именем wg0.conf и следующим содержанием:

Параметр AllowedIPs как раз определяет, какой адрес источника пакетов будет передан в шифрованный канал. В настройках пира для каждого роутера записана подсеть другого роутера — плюс IP адрес пира, которой образуется в результате его подключения, чтобы с VPS сервера можно было достутчаться до хостов во внутренних сетках. Т.е. когда коннектится Keenetic, его пир имеет адрес 10.0.0.2, и пакеты из 192.168.0.0 и с 10.0.0.2 будут отправляться в шифрованный канал. С MikroTik — зеркально.

Теперь надо настроить сервис WG на VPS. На Ubuntu это делается командами:

Эти команды стартуют сервис WG с настройками из указанного конфиг файла, т.е. wg0.conf. Далее надо настроить WG клиенты на роутерах. Начнём с Keenetic.

Не буду тут писать про то, как добавить WG в Keenetic — этой информации полно. После добавления в разделе Internet -> Other connections появится раздел WireGuard, где мы и настроим нужные параметры. Нажмём Add Connection и заполним нужные параметры пира на роутере:

название соединения, заполняем на своё усмотрение

use for accessing internet

не крыжим, иначе весь траффик уйдёт на VPN, а нам это не надо

используем данные из файла keenetic_privatekey

10.0.0.2/24 — это IP адрес роутера Keenetic в сети VPN

я использовал 8.8.8.8

данные из файла publickey самого сервера

<x.x.x.x:ListenPort> — используйте IP адрес VPS и порт, заданный в wg0.conf

0.0.0.0/0 — всё, что приходит на пир, отправляем в VPN

15 — интервал опроса живости интерфейса в секундах

После этого у роутера Keenetic установится соединение с VPN сервером. Далее надо настроить MikroTik. Тут надо отметить, что поддержка WireGuard в MikroTik появилась только с седьмой версии RouterOS, но апгрейд выходит пока за рамки данной статьи и я предполагаю, что вы смогли проапгрейдиться.

Открываем вкладку в WebFig с названием WireGuard и заполняем параметры — это настройки пира на роутере:

любое, у меня 51380

содержимое файла mikrotik_privatekey

Переходим во вкладку Peers, потом Add New, заполняем параметры пира:

Name из предыдущего шага

содержимое publickey сервера

x.x.x.x — IP адрес VPS сервера

Listen Port из wg0.conf

Вот мы и настроили связь между двумя сетями.

Дальше по списку — настройка VPN соединений для выхода, скажем, телефонов, в свободный интернет. Я потратил кучу времени и нервов, и итог получился следующий. Почему так — станет понятно из материала дальше по тексту. По итогу вывод получился следующий — нельзя настроить на одном интерфейсе выход в интернет клиентских устройств и связь между сетями

Поэтому, если я и кто-то из семьи хотим выходить в свободный интернет через VPS сервер, на него придётся добавить новые интерфейсы. Почему же так получается?

Предположим, что на телефон установлено приложение WireGuard, настроены ключи и т.д. Устанавливаем коннект с сервером, и телефон отправляет пакет на зарубежный интернет сервер, скажем, google.com. Пакет отправляется пиром телефона на пир сервера, в интерфейс wg0 . В результате правильной настройки пакет с этого интерфейса форвардится на интерфейс eth1 , подвергается маскараду и натированию, и уходит в большой мир. Сервер google.com отвечает на наш пакет, он приходит на eth1 и форвардится на wg0 , попадая на пир сервера, и тут мы натыкаемся на проблему. В настройках серверного пира указано, пакеты с каких IP адресов или сетей должны уходить в канал. Сервера google.com там сейчас нет, поэтому ответ на телефон просто не вернётся и соединение не будет установлено. Хорошо, добавим в настройки серверного пира для телефона 0.0.0.0/0 , все пакеты будут уходить на телефон — профит. После рестарта интерфейса wg0 мы с удивлением обнаружим, что наш VPS сервер больше недоступен — не пингуется, не коннектится по ssh и текущий терминал вообще завис, потому что теперь весь трафик уходит в пир, даже тот, который для него не предназначен. Именно поэтому организовать на одном интерфейсе желаемую схему нельзя. Ещё одни грабли, на которые я наступил — в рамках одного интерфейса невозможно сделать так, чтобы пакеты уходили в несколько пиров — пакет уходит в тот пир, для которого есть подходящий параметр Allowed IPs.

Но создать новые интерфейсы довольно просто. В папке /etc/wireguard копируем wg0.conf в wg1.conf, и создаём новую ключевую пару:

Для того, чтобы данная конфигурация заработала, необходимо настроить IP forwarding на сервере — иначе пакеты из интерфейса wg1 не будут форвардиться в eth0, т.е. в интернет, и обратно:

Итак, какие ключевые изменения получил конфиг по сравнению с интерфейсом обмена между сетями?

Во-первых, изменился Address, там теперь другая подсеть VPN — 10.0.1.0/24. Соотвественно, и AllowedIPs тоже изменился — все пакеты из этой подсети надо отправлять в peer.

Изменился ListenPort — сервер WG будет принимать соединения для этого интерфейса на другом порту.

Изменились команды PostUp и PostDown — для доступа в интернет недостаточно правил форвардинга, надо ещё и поднимать NAT и masquerade, но это тема совсем другой статьи.

На этом пока всё, настроена интеграция дачной и квартирной сети, и VPN выход в интернет через один и тот же VPS. За кадром пока осталась генерация QR кодов для настройки клиентов — думаю, с этим проблем быть не должно, отмечайте в комментариях, возникают ли проблемы на этом этапе, чтобы было понятно, надо ли обновить мануал.

Как установить и настроить WireGuard VPN на сервере Debian и маршрутизаторе Keenetic

В начале я расскажу как, ну а потом уже зачем использовать WireGuard для построения VPN туннелей. В этой статье я подробно опишу как «связать» между собой внешний сервер с операционной системой Debian и домашний маршрутизатор серии Keenetic.

Как установить WireGuard на Debian или Ubuntu

В репозиториях Debian 10 и Ubuntu 20.04 уже есть пакет WireGuard, поэтому для его установки вам достаточно выполнить одну команду:

в зависимости от ваших привилегий в операционной системе.

Как создать публичный и приватный ключи WireGuard

После того как демон (сервис) WireGuard установлен для организации VPN тоннеля необходимо для каждого устройства создать два ключа: приватный и публичный. В минимальной конфигурации из 2-х участников всего нам понадобятся 4 ключа.

Ключи можно создать на любом устройстве как индивидуально только для него, так и для всех устройств сразу. Команда создания ключей одна, при каждом запуске она создает новый уникальный ключ (пару ключей).

Публичный ключ создается на основе приватного.

Ключ — это просто строка (набор символов), которую мы будем указывать в файлах конфигурации VPN WireGuard. Сгенерированные строки мы запишем в файлы с уникальными названиями, чтобы потом их (строки с набором символов) оттуда взять. Сами файлы ключей напрямую нигде не использутся.

Создадим приватный и публичный ключи на сервере с операционной системой Debian

Для удобства сделаем отдельную директорию для хранения файлов ключей:

А затем создадим ключи для сервера и сохраним их.

Аналогичным способом создадим приватный и публичный ключи клиента.

Команда создания приватного и публичного ключей для клиента ничем не отличается от указанной выше для сервера, изменим лишь имена файлов в которые сохраним сгенерированные кючи:

Если к серверу планируется несколько подключений, то подобным способом можно создать ключи для остальных участников:

Сгенерированные таким способом ключи клиента являются «серверными» для самого клиента. Важно понимать это при настройке устройств. Логичнее именовать файлы с ключами не используя привилегии клиент-сервер, а как в моем примере, unit1, unit2 и т.п. (unit — блок, узел).

Файл конфигурации сервера WireGuard

Создайте любым удобным для вас способом файл конфигурации сервера /etc/wireguard/wg0.conf со следующим содержимым. Я, как правило, использую для этого редактор файлового менеджера Midnight Commander.

Разделов [Peer] в файле конфигурации WireGuard может быть несколько.

Обратите внимание, что при построении VPN тоннеля WireGuard в файле конфигурации первого устройства мы указали приватный ключ сервера (unit1-private) и публичный ключ клиента (unit2-public).

При конфигурации второго устройства VPN WireGuard мы должны использовать unit2-private в качестве ключа сервера, а unit1-public в качестве ключа клиента.

Более наглядно покажу на рисунке:

Общее правило: Для организации связи каждое устройство должно иметь свой приватный ключ и публичные ключи устройств с которыми нужно организовать VPN туннель.

Файл конфигурации клиента WireGuard

Если сервер с операционной системой Debian выступает в роли клиента туннеля WireGuard, то его файл конфигурации будет отличаться от приведенного выше тем, что в нем указывается IP адрес сервера.

Настройка маршрутизатора серии Keenetic в качестве клиента будет описана чуть ниже.

Запуск WireGuard на Debian и Ubuntu

В случае systemd используйте следующую команду для запуска сервиса WireGuard:

Для автозапуска WireGuard при включении сервера выполните следующий код в консоли:

Как установить WireGuard на маршрутизаторе Keenetic

В роутерах торговой марки Keenetic необходимо установить компонент операционной системы Wireguard VPN:

И настроить его в разделе «Другие подключения»:

Добавьте данные сервера:

Если все сделали правильно, то туннель автоматически заработает и останется лишь настроить маршрутизацию трафика.

Для чего используют VPN

VPN используют для объединения в единую сеть нескольких компьютеров (серверов) через интернет. При этом доступ в эту сеть могут получить только устройства этой сети. То есть задача VPN не только передать информацию между вашими компьютерами, но и защитить ее (информацию) от посторонних глаз.

Таким способом вы можете объединить системы находящиеся в разных городах и даже странах.

Обход блокировок Рунета

Одним из частных случаев использования VPN является обход блокировок доступа к тем или иным сайтам.

Не всегда заблокированные сайты «плохие». Вот реальный пример блокировки доступа к сайту М.Видео. Вот уже несколько дней вся подсеть моего провайдера заблокирована и посетить этот интернет магазин невозможно.

А во время «ковровых бомбардировок» РКН (Роскомнадзор) проблем бывает еще больше, достаточно вспомнить попытки заблокировать мессенджер Телегам в России. Тогда пострадало много невинных ресурсов, один из них — сайт архиватора 7-zip.org, доступ к которому можно было получить только через зарубежные VPN.

Почему WireGuard?

Это «свежий» VPN с открытым исходным кодом. В нем используется самая современная криптография. Он прост в настройке и потребляет мало ресурсов, что особенно важно при его работе на домашнем роутере. Он кроссплатформенный и может работать практически где угодно.

Соединяю локальные сети через VPS-сервер и Keenetic посредством WireGuard VPN

Сегодня случилось страшное. Мой провайдер MosLine, без каких-либо объявлений или предупреждений сменил мне публичный IPv4 адрес на частный. В результате отключились две важные для меня функции: связь нескольких разрозненных локальных сетей и туннелирование IPv6 (использовался 6in4 вариант туннелирования, когда требуется наличие «белого» IPv4 адреса), поскольку MosLine (вкупе с его дочерней Optic-Inet) так и не научился раздавать своим клиентам IPv6. Собственно, отключение вбило очередной гвоздик в гробик провайдера, так как я уже сейчас могу получить минимум вдвое более быстрый канал через мобильную сеть и вдвое дешевле (см. статью о современных средствах добычи мобильного интернета). И единственные две вещи, которые меня останавливают от перехода на более дешевого альтернативного провайдера, так это необходимость перекраивания внутренней локальной инфраструктуры, а также необходимость инвестирования в новое оборудование. Ну и ping на мобильной сети не такой комфортный, как на оптике. И пока я раздумываю над сменой провайдера, необходимо закрыть хотя бы первую функцию, а именно связать разрозненные локальные сети в единое информационное пространство. Благо, у меня есть несколько VPS-серверов, которые можно оперативно использовать для решения этой проблемы.

Итак, в качестве инфраструктуры у меня используются роутеры, или как говорят англоязычные специалисты «рутеры», Keenetic. Может быть, данные роутеры не самые продвинутые в плане настроек, но они не кушают мозг в процессе эксплуатации (один раз настроил и работает годами), а при самой настройке нет необходимости бегать кругами вокруг роутера, курить трубку и бить в бубен исполняя тотемный танец по призыву коллективного разума с вопросом «а почему не работает». На стороне VPS, как водится, у меня крутится разновидность Linux.

Локальные сети еще издревле соединялись между собой через сети общего пользования посредством VPN-технологии. За десятилетия развития VPN появилось несметное некоторое количество вариантов VPN-протоколов и соответствующего программного обеспечения. Традиционно для VPN используются такие варианты VPN-протоколов, как IPSec/L2TP, PPTP или OpenVPN. Но в последнее время все больше набирает популярность такой протокол для организации VPN как WireGuard. Создатели WireGuard позиционируют свое решение как быстрое, современное и безопасное решение для организации виртуальных частный сетей. И судя по тестам, заявления совсем не беспочвенные. WireGuard работает весьма шустро, кушает очень мало ресурсов и поддерживается актуальными системами (как на Linux, так и на Windows, Android и т. п.), что позволяет соединять вместе различные устройства, работающие под разными операционными системами. Но помимо легковесности и безопасности у WireGuard есть еще одно преимущество, его довольно-таки просто установить и настроить.

В сети существует множество инструкций о том, как установить WireGuard в виде любого сетапа, на любое устройство и для любых целей. Не буду их повторять, но порекомендую, исключительно для облегчения и ускорения процесса, воспользоваться WireGuard installer. Скрипт устанавливает WIreGuard на основные Linux дистрибутивы и позволяет осуществлять простую настройку как сервера, так и облегчает добавление новых пиров к серверу. В принципе, для WireGuard существует около двух десятков установщиков, поэтому не обязательно, особенно если есть силы, использовать указанный выше скрипт-инсталлятор. Вполне можно обойтись другим решением или установить все руками с начала и до конца.

Итак, скачав скрипт, дав ему права и, наконец, запустив wireguard-install.sh, а затем ответив на несколько примитивных вопросов или просто понажимав Enter, можно наконец выдохнуть. По умолчанию, скрипт добавляет одного клиента (пира). Для добавления нового или удаления старых клиентов (пиров) необходимо запустить скрипт еще раз. Ну или отредактировать текстовой конфигурационный файл. Он, как правило, располагается в /etc/wireguard и называется аналогично названию WireGuard интерфейса, обыкновенно это wg0.conf. Данный файл можно редактировать текстовым редактором, однако, для того, чтобы изменения вступили в силу, следует перезапустить WireGuard. Остановка и последующий запуск осуществляются через команду wg-quick [down|up] wg0. Где wg0 как раз название интерфейса/имя конфигурационного файла.

Вообще, в рамках WireGuard нет такого понятия как сервер и клиент. Есть понятие пиры. Так подняв «сервер» на VPS и прописав в нем «клиента» я просто создал возможность для соединения этих устройств. Но никто из них не будет являться сервером, в классическом понимании. Разделение в WireGuard на относительный «сервер» и потенциального «клиента» лишь в том, кто сам пытается соединиться (клиент), а кто просто ожидает соединения (сервер).

При создании клиентов через скрипт, он выводит на экран могучий QR-код, который можно использовать, чтобы подцепить настройки подключения, например, мобильным телефоном. Параллельно настройки клиента складываются в каталог, откуда запускается скрипт, в файл с именем wg0-client-S21.conf. В данном случае в имени зашифровано название интерфейса wg0, и наименование клиента S21. Вся эта же информация копируется и в основной конфигурационный файл wg0.conf (тот, который в /etc/wireguard). Если потребуется внести изменения в конфигурацию, то редактировать нужно именно wg0.conf, так как «клиентские» файлы нужны исключительно для импорта в клиентские инсталляции.

Пробежимся по основному конфигурационному файлу, который сгенерировал для моей инсталляции скрипт. Файл сформирован для интерфейса wg0. Разумеется, все ключи, как приватные, так и публичные, удалены из файла, равно как и публичные IP-адреса.

В рассматриваем примере есть три секции, соответственно одна Interface для задания настроек «серверной» части WireGuard для конкретного интерфейса и две секции Peer для «клиентов-пиров». Авторами WireGuard предполагается, что система настолько простая, что никакая документация для нее не нужна. Поэтому ее особо и нет. Однако, не все настолько проницательны и готовы перелопатить 4000 строк исходного кода, чтобы разобраться, что к чему. Поэтому в сети появилась неофициальная документация по WireGuard. Я же попробую вкратце пробежаться по всем приведенным параметрам, с дополнительными комментариями там, где они нужны, так как из-за отсутствия официальной документации иногда не просто сообразить какой параметр куда вставлять, чтоб наконец заработало.

Итак, в секции Interface задаются параметры настроек для «серверной части» WireGuard. В параметре Address перечисляются через запятую внутренние адреса интерфейса в нотации CIDR. Тут следует обратить внимание на то, что используется не только внутренний IP-адрес внутри виртуальной частной сети (VPN) в пространстве IPv4, но и в адресном пространстве IPv6. Обратите внимание, что в обоих случаях /24 и /64 назначается целая подсеть. Для IPv4 в эту подсеть можно уместить до 254 адресов, а для IPv6 их будет уже 18.446.744.073.709.551.616 штук, такова особенность IPv6, адресов там невообразимо много. Еще одно замечание, обе подсети относятся к «частным» пулам адресов. Кстати, Address может быть указан и для единственного адреса, а не для сети. В этом случае никакой маршрутизации по сети, к которой относится указанный адрес, производиться не будет. Следующий параметр ListenPort означает порт, который интерфейс «слушает» и принимает входящие соединения. Если не указать порт, то соответственно никто подключиться к интерфейсу извне не сможет, однако, возможность маршрутизации останется.

PrivateKey – частный ключ, который не сообщается ни одному из пиров. Этот ключ используется только на стороне «сервера». При задании ключей можно обратить внимание, что они все оканчиваются на символ ‘=’.

PostUp и PostDown команды выполняемые после включения и отключения интерфейса соответственно. Здесь указываются именно команды в том виде, в котором они будут переданы интерпретатору операционной системы. Команды могут быть перечислены через точку с запятой или же можно указать несколько параметров PostUp и PostDown. В моем примере скриптом-установщиком сгенерированы команды маршрутизации посредством iptables. Соответственно при «поднятии» интерфейса эти правила применяются, а после отключения удаляются. Таким образом сохраняется стабильность сетевого трафика и сетевые пакеты не будут улетать в неизвестном направлении.

Помимо перечисленных параметров в конфигурационном файле могут применяться и другие параметры. PreUp и PreDown параметры аналогичны PostUp и PostDown, но выполняются перед действием «поднятия» или отключения интерфейса. Параметр DNS применяется для передачи подключаемым пирам адресов DNS-серверов посредством DHCP-протокола. Но обычно, клиенты прописывают DNS-сервера на своей стороне и игнорируют DNS-сервера предлагаемые со стороны сервера. Серверов можно указать несколько, через запятую, равно как и использовать не только IPv4, но и IPv6 адреса.

MTU устанавливает максимальный размер величины единичного пакета или фрейма с данными. Как правило, данный параметр устанавливается автоматически, базируясь на настройках подключаемого пира или уже используемой маршрутизации в системе. При настройке секции Interface можно использовать еще один параметр Table. Он указывает на используемую таблицу маршрутизации в операционной системе, что полезно в случае сложного сетевого окружения на крупных узлах.

При настройке секции Peer в WireGuard присутствует правило хорошего тона: каждую секцию предварять строкой комментария с наименованием пира. Когда пиров или клиентов становится много, то понять кто из них кто становится очень не просто. При генерации пиров через скрип-инсталлятор, он каждую секцию Peer предваряет символами комментария ### и последующим наименованием пира. Несмотря на наименования пиров в файле конфигурации, в самом WireGuard, например, при выводе статистики соединений, эти наименования никак не будут отражаться, что, разумеется, не так удобно. Опознать нужный пир можно только по адресу или же по публичному ключу.

PublicKey – публичный ключ для клиента, данные передаваемые клиенту шифруются этим ключом, следует обратить внимание, что в конфигурационных файлах пиров-клиентов этот ключ другой. PresharedKey – еще один уровень защиты применяемый для шифрования канала. Этот ключ смешивается вместе с парой открытого и закрытого ключей и необходим как последний аргумент в защите зашифрованного канала. Если злоумышленник каким-то образом вытащит приватный ключ, то он все равно не сможет расшифровать поток данных, так как ему потребуется узнать и PresharedKey. Однако, этот параметр опциональный, если его не указать, то «совместно используемый ключ» будет состоять из нулей. Разумеется, PresharedKey должен идентичен на стороне сервера и на стороне клиента.

AllowedIPs – список IP-адресов в CIDR нотации, т.е. это могут быть не только адреса конечных машин, но и сетей. Адрес может быть указан из IPv4 или IPv6 адресного пространства. Этот список определяет адреса, которые будут маршрутизироваться непосредственно в этот пир. При запуске интерфейса выполняется команда добавления маршрута на подобии ip route add …. Параметр довольно-таки важный, особенно важно обратить на него внимание, если требуется маршрутизировать целую сеть, которая находится за устройством пира. В рассматриваемом примере для пира Dacha указано целых три адреса, а именно:

• 10.66.66.2/32 – адрес машины в подсети создаваемой VPN. 10.66.66.1 это адрес собственно сервера WireGuard, а 10.66.66.2 это адрес роутера Keenetic.
• 192.168.0.0/24 – адрес сети за пиром (роутером Keenetic), я хочу, чтобы WireGuard сервер прокидывал туда пакеты, которые будут попадать на его интерфейс.
• fd42:42:42::2/128 – адрес машины в подсети создаваемой VPN, но в адресном пространстве IPv6.

С использованием смекалки и параметра AllowedIPs можно городить весьма странные и запутанные конфигурации для маршрутизирования пакетов. Иногда сообразить руками все пересечения сетей и адресов проблематично, но в этом случае можно воспользоваться специализированными калькуляторами, например, от Pro Custodibus-а.

EndPoint – в настройках сервера он не указан, так как все мои клиенты находятся на «серых», непубличных IPv4 адресах и к ним извне невозможно подключиться. Указывается в виде адрес:порт, допускается использование как доменного имени, так и IPv4 или IPv6 адреса. А поскольку на стороне сервера мы только слушаем, то и параметр PersistentKeepalive, определяющий периодическую проверку соединения в секундах и его переинициализацию в случае потери связи, благополучно отсутствует.

Вот, собственно, и все настройки, которые доступны на сервере. На клиенте, в общем-то доступны все те же настройки, так как в WireGuard нет такого понятия как клиент или сервер, есть только пиры. При добавлении пира через скрипт-инсталлятор на VPS-сервере он не только добавляет его в файл для настройки пира, но и в общий конфигурационный файл интерфейса WireGuard (тот самый wg0.conf). Посмотрим на него повнимательнее (это конфигурация пира Dacha).

При генерации настроек пира скрипт создает уникальные пары ключей, а именно «Частный ключ 2» и «Публичный ключ 2б». Они нигде не фигурируют в общем конфигурационном файле интерфейса wg0.conf. Более того, сгенерированные файлы настроек пиров можно вообще удалить после импорта настроек в клиентов. Дополнительно следует обратить внимание на то, что «Совместно используемый ключ 2» он одинаков как со стороны настроек клиента, так и со стороны настроек сервера.

В секции Interface присутствует всего три параметра:

• PrivateKey – содержит частный ключ пира, он отличается от серверного ключа.
• Address – содержит уникальный в разрезе создаваемой VPN адрес пира. Прошу обратить внимание, что тут указывается именно адрес конкретной машины, роутера, телефона, устройства в общем, а не сети.
• DNS – те сервера DNS, которые будут использоваться для разрешения мнемонических адресов в цифровые, вполне можно не указывать, особенно, если вы не планируете использовать VPN для выхода в интернет.

В секции Peer уже четыре параметра:

• PublicKey – публичный ключ. Следует обратить внимание, что этот ключ отличается от ключа в настройках сервера.
• PresharedKey – совместно используемый ключ для улучшения защиты от угона компрометации ключей шифрования. Здесь он совпадает с тем, что указаны в настройках сервера.
• EndPoint – публичный адрес и порт сервера, на котором он принимает подключения VPN. Может быть IPv4, IPv6 или мнемоническим адресом, типа vpn.microsoft.ucoz.net.

В примере выше отсутствует такой важный для клиентской части параметр, как PersistentKeepalive (он описан в серверной части). WireGuard относится к так называемым Stateless (или скорее Connection-less) системам, системам, в данном контексте, которые не беспокоятся о состоянии VPN-канала, не поддерживают его в постоянно подключенном состоянии. Так, подключившись однажды и не передавая никакой трафик, система будет думать, что VPN-канал установлен и находится в полном рабочем состоянии. Даже в статистике WireGuard пир будет обозначен как живой, правда последняя активность на нем была, ну скажем 148 часов тому назад. Вот тут и помогает настройка PersistentKeepalive, которую нужно устанавливать на пире, который будет подключаться к серверу. В нашем случае это Keenetic без публичного IP-адреса. Обычно параметр PersistentKeepalive устанавливают равным нескольким десяткам секунд. Именно с этой периодичностью WireGuard со стороны пира, подключающегося к серверу (по сути, он тоже пир, только сам никуда не подключается), будет проверять работоспособность канала и если она нарушена, то будет инициализировать его восстановление.

С серверной настройкой все сделано, теперь очередь за Keenetic-ом. В современных версиях операционной системы для Кинетиков есть возможность установки дополнительных модулей. Для установки WireGuard необходимо выбрать соответствующий компонент в настройках операционной системы роутера. После чего применить настройки. Компонент скачается и установится.

Следующим шагом будет создание интерфейса подключения к «серверу». Подключения через WireGuard настраиваются и создаются на страничке «Другие подключения» в группе «Интернет». В соответствующей части страницы жмем «Добавить подключение» и тут у нас появляется форма для добавления нового интерфейса и заодно пира (или нескольких) для подключения.

Интерфейс настройки WireGuard на Keenetic

Приведу расшифровку полей интерфейса настройки подключения у Keenetic:

1. Название интерфейса. Следует сделать его понятным, поскольку в дальнейшем он будет использоваться еще в других местах.
2. Если поставить галку, то весь трафик с роутера во вне будет уходить в установленный туннель. Для соединения локальных сетей не ставим.
3. Поле для ввода приватного ключа. Генерировать новую пару не стоит, так как эту работу уже проделал скрипт-инсталлятор. Нужно скопировать «Частный ключ 2» из сгенерированного на сервере файла для данного пира и нажать на кнопку «Установить частный ключ».
4. Вводим адрес данного устройства в сети VPN. Опять же, берем его с сгенерированного на сервере файла. Обязательно указываем модификатор /32, отображающий, что это конкретное устройство, а не подсеть. Используем только IPv4 адрес, так как WireGuard для Keenetic еще не научился работать с IPv6 (и это печально на самом деле).
5. Указываем имя пира, к которому роутер будет подключаться для установления связи. Пиров можно задавать несколько, но это имеет смысл, если роутер выступает в качестве сервера.
6. Указываем «Публичный ключ 2б» из файла.
7. Указываем «Совместно используемый ключ 2» из файла.
8. Указываем адрес и порт, к которому подключаемся для создания VPN-туннеля. Параметр Endpoint из файла.
9. Оставляем как есть 0.0.0.0/0.

Дополнительные параметры настройки подключения: порт прослушивания оставляем пустым, так как мы не планируем получать подключения к Keenetic-у, наоборот, он сам будет подключаться к серверу. DNS сервера можно указать, можно не указывать. Они нужны только в случае, если VPN будет использоваться для выхода в Internet. Размер MTU можно оставить пустым, если, конечно, специально нет задачи его изменить. «Подстройка TCP MSS» оставляем включенной.

В поле «Разрешенные подсети», кроме 0.0.0.0/0 правильнее было бы перечислить все сети из AllowedIPs серверного конфигурационного файла (wg0.conf или аналогичного), но в реализации WireGuard для Keenetic это поле не вызывает включение маршрутизации до этих адресов и сетей при «поднятии» туннеля с сервером. Маршрутизация настраивается отдельно. Об этом ниже.

Если сейчас все сохранить и включить ползунком подключение к серверу VPN, то все подключится. Вот только работать не будет. Для включения полной работоспособности нужно настроить «Межсетевой экран» и маршрутизацию.

Настройка межсетевого интерфейса

Настройка межсетевого экрана осуществляется просто, достаточно разрешить все действия для всех адресов источника и назначения для протокола IP и включить правило на созданном интерфейсе. Можно правила усложнить, фильтровать адреса, перебирать протоколы и так далее.

Настройка маршрутизации на Keenetic

Следующим этапом необходимо включить маршрутизацию пакетов к удаленным сетям. Так как у нас не планируется пускать весь трафик через VPN, то следует определиться, к каким сетям следует включить маршрутизацию. В рассматриваемом сетапе необходимо включить маршрут к самой сети VPN, а именно 10.66.66.0/24. Иначе, даже ping работать не будет. Роутер получит ICMP-запрос на ping, обработает его, но ответный пакет отправит не через VPN, а по маршруту по умолчанию, т.е. провайдеру. При задании маршрута адрес сети/устройства можно указывать в формате CIDR, можно только традиционным путем с указанием отдельной маски. Адрес шлюза указывать нет необходимости, так как мы выбираем целиком интерфейс, созданный для подключения к WireGuard VPN. Галочка «Добавлять автоматически» делает ровно то, что делает PostUp/PostDown на сервере: если интерфейс включен, то включается маршрут, если он отключен, то маршрут аналогично отключается.

В приведенном примере в качестве пиров-клиентов у меня указан только смартфон и один роутер Keenetic. В действительности пиров-Keenetic-ов с локальными сетями за ними несколько больше. И на каждом из них следует прописать отдельный маршрут к удаленной сети с прохождением через настроенный WireGuard интерфейс. Иначе роутер не будет отправлять пакеты по VPN, хотя все сети к этой сети подключены. При изменении настроек файрволла (межсетевого экрана) и маршрутизации необходимо учитывать, что на кинетиках данные настройки иногда не включаются моментально, а им требуется некоторое время, прежде чем они заработают.

Как проверять соединение? Самыми обычными средствами, а именно посредством ping и traceroute (tracert). Пинговать следует как со стороны сервера, так и со стороны клиента. Для начала пингуются адреса сервера и клиента в локальной сети VPN-а, в нашем случае это 10.66.66.1 и 10.66.66.2. Затем пингуются устройства, находящиеся внутри подключаемой локальной сети, начать можно с адреса роутера в этой локальной сети, в нашем случае это 192.168.0.1. В сложных случаях понять, что не так, может помочь трассировка, тогда становится понятно, где проблема, если пакет, вместо того чтобы двигаться в туннель, вдруг уходит провайдеру интернета. Одной из интересных и часто встречающихся проблем является ошибка ping: sendmsg: Destination address required. Возникает она, как правило, при забывчивости настройки AllowedIPs на стороне сервера для конкретных клиентов.

Насколько сильно WireGuard грузит сервер? Вопрос очень интересный. Разрабатывался WireGuard не только как простой в использовании инструмент для создания VPN, но еще и весьма быстрое, не требовательное к ресурсам решение. Но, а как оно в реальных условиях? На двухпроцессорном VPS нагрузка при копировании файла между двумя пирами на скорости 80 Мбит составляла порядка 10%. Дополнительный расход памяти на работу WireGuard при активных сетевых операциях зафиксировать не удалось. Другими словами, нагрузка на процессор есть, но она минимальна, тем более что в реальности трафик через VPN не настолько велик и тем более, не постоянен.

Что означает «Последнее рукопожатие» в интерфейсе WireGuard на Keenetic? WireGuard VPN для своей работы использует протокол UPD, в отличии от TCP, в нем не гарантирована доставка пакетов от одного адресата до другого. Пакеты могут не доходить, могут теряться, могут доходить разными маршрутами и, как следствие, в неверном порядке. Все это ведет к тому, что нарушается целостность VPN-соединения. WireGuard автоматически исправит эти нарушения, но ситуация может потребовать переустановления связи. Более того, при нормальной работе, когда не нарушается обмен пакетами, пиры в автоматическом режиме через случайные промежутки времени обмениваются новыми парами ключей шифрования. Делается это специально для усложнения расшифровки зашифрованного потока данных. Обе эти операции приводят к сбросу счетчика последнего рукопожатия.

PS. Кстати, в мире существует еще одно интересное решение для организации VPN в сложных условиях, например, когда нет административных прав на сервере или требуется проходить через довольно строгие NAT и FireWall. Имя ему SoftEther VPN, но для решения моей задачи он излишне тяжеловат.