- Специальный корреспондент
В данной статье я поделюсь опытом и конфигами для построения универсального семейного VPN - как для конечных потребителей, так и для организации сетевого взаимодействия между дачей и квартирой.
Вы узнаете, как:
Конечно, разных статей про WG много - тем не менее, когда мне понадобилось решить комплексную задачу, те статьи, которые я находил, мне не помогали. Рискну предположить, что так происходило потому, что в большинстве статей приводится рецепт без объяснения механики происходящего, поэтому шаг влево или вправо делает инструкцию бесполезной. Я хочу ликвидировать этот пробел и дать читателю в руки не только инструкцию, но и понимание, как это работает, чтобы он имел возможность реализовать что-то из того, что нигде не описано.
Для начала опишу задачу, которая у меня возникла и которая была успешно решена. Исходной отправной точкой была идея связать два сетевых сегмента - на даче и в квартире, чтобы можно было админить одну сетку из другой и наоборот. Так сложилось, что среда оказалась гетерогенной - дома стоит роутер Keenetic Viva, доступ к его админке есть из интернета благодаря технологиям Keenetic, а вот на даче стоит MirkoTik RB3011, и у местного провайдера нет услуг типа публичного IP. Идея витала давно, но драйвером реализации стало то, что классный VPN Windscribe перестал работать через моего провайдера совсем. Я решил арендовать VPS за рубежом, настроить VPN для членов семьи, и заодно связать две сетки - как вишенка на торте. Целевая архитектура выглядит так:
Был арендован VPS сервер у провайдера Fornex[ссылка удалена модератором], в качестве отправной статьи для настройки WireGuard была использована . Далее идём по порядку - я использовал рутовый аккаунт, поэтому команды без sudo.
Устанавливаем WG:
apt install -y wireguard
Переходим в каталог /etc/wireguard и все всё делаем там. Пока всё согласно инструкции - генерим ключевую пару для сервера:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickey
В результате у нас появятся два ключа - закрытый и публичный, они будут использоваться для подключений к WG серверу. Теперь пришло время вернуться к изучению матчасти - как работает WG, какими сущностями оперирует и к чему это всё приводит. Упрощённо схема работы WG выглядит так:
Данная схема описывает следующие факты и соображения:
Сначала разберём поток пакетов из квартирной сети в сеть дачи и обратно. Предположим, что у нас есть следующие параметры:
Касательно подсети VPN - можно задать любую подсеть из числа внутренних, непубличных адресов. Я у себя выбрал такую, у вас может быть любая, соответствующая критерию внутренней.
Пойдём по шагам.
Для начала настроим интерконнект между двумя сетями - квартира и дача. Прежде, чем это сделать, надо сгенерировать ключевые пары для пиров квартиры и дачи, т.е. для их роутеров:
wg genkey | tee /etc/wireguard/keenetic_privatekey | wg pubkey | tee /etc/wireguard/keenetic_publickey
wg genkey | tee /etc/wireguard/mikrotik_privatekey | wg pubkey | tee /etc/wireguard/mikrotik_publickey
Сформируем файл в каталоге /etc/wireguard с именем wg0.conf и следующим содержанием:
[Interface]
PrivateKey = <здесь privatekey> # Приватный ключ из файла privatekey.
Address = 10.0.0.1/24 #Адрес VPN-сервера в частной сети.
ListenPort = 51830 #Порт, который будет слушать VPN-сервер.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
[Peer]
PublicKey = <keenetic_publickey> #Публичный ключ роутера Keenetic
AllowedIPs = 192.168.0.0/24, 10.0.0.2
[Peer] PublicKey = <mikrotik_publickey> #Публичный ключ роутера Mikrotik
AllowedIPs = 192.168.88.0/24, 10.0.0.3
Параметр AllowedIPs как раз определяет, какой адрес источника пакетов будет передан в шифрованный канал. В настройках пира для каждого роутера записана подсеть другого роутера - плюс IP адрес пира, которой образуется в результате его подключения, чтобы с VPS сервера можно было достутчаться до хостов во внутренних сетках. Т.е. когда коннектится Keenetic, его пир имеет адрес 10.0.0.2, и пакеты из 192.168.0.0 и с 10.0.0.2 будут отправляться в шифрованный канал. С MikroTik - зеркально.
Теперь надо настроить сервис WG на VPS. На Ubuntu это делается командами:
systemctl enable [email protected]
systemctl start [email protected]
Эти команды стартуют сервис WG с настройками из указанного конфиг файла, т.е. wg0.conf. Далее надо настроить WG клиенты на роутерах. Начнём с Keenetic.
Не буду тут писать про то, как добавить WG в Keenetic - этой информации полно. После добавления в разделе Internet -> Other connections появится раздел WireGuard, где мы и настроим нужные параметры. Нажмём Add Connection и заполним нужные параметры пира на роутере:
После этого у роутера Keenetic установится соединение с VPN сервером. Далее надо настроить MikroTik. Тут надо отметить, что поддержка WireGuard в MikroTik появилась только с седьмой версии RouterOS, но апгрейд выходит пока за рамки данной статьи и я предполагаю, что вы смогли проапгрейдиться.
Открываем вкладку в WebFig с названием WireGuard и заполняем параметры - это настройки пира на роутере:
Переходим во вкладку Peers, потом Add New, заполняем параметры пира:
Вот мы и настроили связь между двумя сетями.
Дальше по списку - настройка 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, и создаём новую ключевую пару:
wg genkey | tee /etc/wireguard/user1_privatekey | wg pubkey | tee /etc/wireguard/user1_publickey
Редактируем wg1.conf
[Interface]
PrivateKey = <здесь тот же серверный private key> # Приватный ключ из файла privatekey.
Address = 10.0.1.1/24 #Адрес VPN-сервера в частной сети.
ListenPort = 51831 #Порт, который будет слушать VPN-сервер.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при поднятии сервера
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при выключении сервера
[Peer]
PublicKey = <публичный ключ user1> #Публичный ключ user1
AllowedIPs = 10.0.1.0/24
Для того, чтобы данная конфигурация заработала, необходимо настроить IP forwarding на сервере - иначе пакеты из интерфейса wg1 не будут форвардиться в eth0, т.е. в интернет, и обратно:
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
Итак, какие ключевые изменения получил конфиг по сравнению с интерфейсом обмена между сетями?
Во-первых, изменился Address, там теперь другая подсеть VPN - 10.0.1.0/24. Соотвественно, и AllowedIPs тоже изменился - все пакеты из этой подсети надо отправлять в peer.
Изменился ListenPort - сервер WG будет принимать соединения для этого интерфейса на другом порту.
Изменились команды PostUp и PostDown - для доступа в интернет недостаточно правил форвардинга, надо ещё и поднимать NAT и masquerade, но это тема совсем другой статьи.
На этом пока всё, настроена интеграция дачной и квартирной сети, и VPN выход в интернет через один и тот же VPS.
Вы узнаете, как:
- настроить на VPS сервере WireGuard
- организовать связь через WireGuard между двумя домашними сетями без публичных IP
- организовать выход с клиентских устройств в интернет без границ, если ваш VPS находится на иностранной площадке
сокращение | расшифровка |
WG | WireGuard |
Для начала опишу задачу, которая у меня возникла и которая была успешно решена. Исходной отправной точкой была идея связать два сетевых сегмента - на даче и в квартире, чтобы можно было админить одну сетку из другой и наоборот. Так сложилось, что среда оказалась гетерогенной - дома стоит роутер Keenetic Viva, доступ к его админке есть из интернета благодаря технологиям Keenetic, а вот на даче стоит MirkoTik RB3011, и у местного провайдера нет услуг типа публичного IP. Идея витала давно, но драйвером реализации стало то, что классный VPN Windscribe перестал работать через моего провайдера совсем. Я решил арендовать VPS за рубежом, настроить VPN для членов семьи, и заодно связать две сетки - как вишенка на торте. Целевая архитектура выглядит так:
Был арендован VPS сервер у провайдера Fornex[ссылка удалена модератором], в качестве отправной статьи для настройки WireGuard была использована . Далее идём по порядку - я использовал рутовый аккаунт, поэтому команды без sudo.
Устанавливаем WG:
apt install -y wireguard
Переходим в каталог /etc/wireguard и все всё делаем там. Пока всё согласно инструкции - генерим ключевую пару для сервера:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey | tee /etc/wireguard/publickey
В результате у нас появятся два ключа - закрытый и публичный, они будут использоваться для подключений к WG серверу. Теперь пришло время вернуться к изучению матчасти - как работает WG, какими сущностями оперирует и к чему это всё приводит. Упрощённо схема работы WG выглядит так:
Данная схема описывает следующие факты и соображения:
- В результате запуска WG сервера поднимается отдельный сетевой интерфейс на хосте.
- Конфигурация WG сервера применяется к сетевому интерфейсу.
- Для каждого клиентского соединения на стороне сервера настраивается свой peer, он же пир.
- Защищённый канал устанавливается между двумя пирами.
- Сервер не настраивает параметры клиентских пиров, он настраивает только свои пиры.
Сначала разберём поток пакетов из квартирной сети в сеть дачи и обратно. Предположим, что у нас есть следующие параметры:
подсеть квартиры, Keenetic | 192.168.0.0/24 |
подсеть дачи, MikroTik | 192.168.88.0/24 |
IP адрес VPS | x.x.x.x |
подсеть VPN | 10.0.0.0/24 |
Пойдём по шагам.
- Настроить сервер 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 genkey | tee /etc/wireguard/keenetic_privatekey | wg pubkey | tee /etc/wireguard/keenetic_publickey
wg genkey | tee /etc/wireguard/mikrotik_privatekey | wg pubkey | tee /etc/wireguard/mikrotik_publickey
Сформируем файл в каталоге /etc/wireguard с именем wg0.conf и следующим содержанием:
[Interface]
PrivateKey = <здесь privatekey> # Приватный ключ из файла privatekey.
Address = 10.0.0.1/24 #Адрес VPN-сервера в частной сети.
ListenPort = 51830 #Порт, который будет слушать VPN-сервер.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
[Peer]
PublicKey = <keenetic_publickey> #Публичный ключ роутера Keenetic
AllowedIPs = 192.168.0.0/24, 10.0.0.2
[Peer] PublicKey = <mikrotik_publickey> #Публичный ключ роутера Mikrotik
AllowedIPs = 192.168.88.0/24, 10.0.0.3
Параметр AllowedIPs как раз определяет, какой адрес источника пакетов будет передан в шифрованный канал. В настройках пира для каждого роутера записана подсеть другого роутера - плюс IP адрес пира, которой образуется в результате его подключения, чтобы с VPS сервера можно было достутчаться до хостов во внутренних сетках. Т.е. когда коннектится Keenetic, его пир имеет адрес 10.0.0.2, и пакеты из 192.168.0.0 и с 10.0.0.2 будут отправляться в шифрованный канал. С MikroTik - зеркально.
Теперь надо настроить сервис WG на VPS. На Ubuntu это делается командами:
systemctl enable [email protected]
systemctl start [email protected]
Эти команды стартуют сервис WG с настройками из указанного конфиг файла, т.е. wg0.conf. Далее надо настроить WG клиенты на роутерах. Начнём с Keenetic.
Не буду тут писать про то, как добавить WG в Keenetic - этой информации полно. После добавления в разделе Internet -> Other connections появится раздел WireGuard, где мы и настроим нужные параметры. Нажмём Add Connection и заполним нужные параметры пира на роутере:
параметр | значение |
Name | название соединения, заполняем на своё усмотрение |
use for accessing internet | не крыжим, иначе весь траффик уйдёт на VPN, а нам это не надо |
Private key | используем данные из файла keenetic_privatekey |
Address | 10.0.0.2/24 - это IP адрес роутера Keenetic в сети VPN |
Listen port | вообще любой |
DNS | я использовал 8.8.8.8 |
Peer name | любой |
Public key | данные из файла publickey самого сервера |
Endpoint | <x.x.x.x:ListenPort> - используйте IP адрес VPS и порт, заданный в wg0.conf |
Allowed IPs | 0.0.0.0/0 - всё, что приходит на пир, отправляем в VPN |
Persistent keepalive | 15 - интервал опроса живости интерфейса в секундах |
Открываем вкладку в WebFig с названием WireGuard и заполняем параметры - это настройки пира на роутере:
параметр | значение |
Name | любое |
Listen Port | любое, у меня 51380 |
Private Key | содержимое файла mikrotik_privatekey |
параметр | значение |
Interface | Name из предыдущего шага |
Public Key | содержимое publickey сервера |
Endpoint | x.x.x.x - IP адрес VPS сервера |
Endpoint Port | Listen Port из wg0.conf |
Allowed Address | 0.0.0.0/0 |
Дальше по списку - настройка 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, и создаём новую ключевую пару:
wg genkey | tee /etc/wireguard/user1_privatekey | wg pubkey | tee /etc/wireguard/user1_publickey
Редактируем wg1.conf
[Interface]
PrivateKey = <здесь тот же серверный private key> # Приватный ключ из файла privatekey.
Address = 10.0.1.1/24 #Адрес VPN-сервера в частной сети.
ListenPort = 51831 #Порт, который будет слушать VPN-сервер.
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при поднятии сервера
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE #Команды, который будут выполнять при выключении сервера
[Peer]
PublicKey = <публичный ключ user1> #Публичный ключ user1
AllowedIPs = 10.0.1.0/24
Для того, чтобы данная конфигурация заработала, необходимо настроить IP forwarding на сервере - иначе пакеты из интерфейса wg1 не будут форвардиться в eth0, т.е. в интернет, и обратно:
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
Итак, какие ключевые изменения получил конфиг по сравнению с интерфейсом обмена между сетями?
Во-первых, изменился Address, там теперь другая подсеть VPN - 10.0.1.0/24. Соотвественно, и AllowedIPs тоже изменился - все пакеты из этой подсети надо отправлять в peer.
Изменился ListenPort - сервер WG будет принимать соединения для этого интерфейса на другом порту.
Изменились команды PostUp и PostDown - для доступа в интернет недостаточно правил форвардинга, надо ещё и поднимать NAT и masquerade, но это тема совсем другой статьи.
На этом пока всё, настроена интеграция дачной и квартирной сети, и VPN выход в интернет через один и тот же VPS.
