🛡️ GANVAS VPN
EN Скачать
← Все статьи

WireGuard от А до Я: как работает и как настроить свой конфиг/сервер

WireGuard — самый современный и, пожалуй, самый удобный VPN-протокол на сегодняшний день. Он быстрый, компактный, легко настраивается и одинаково хорошо работает на сервере, ноутбуке, телефоне и даже на роутере. Если вы хотите понять, как именно устроен туннель, разобрать конфиг по полям и поднять собственный сервер — эта статья проведёт вас от базовых понятий до рабочей инсталляции.

Сразу важная мысль: WireGuard — это открытый стандарт, а не чья-то проприетарная технология. Ваш собственный WireGuard-конфиг будет работать в GANVAS VPN бесплатно — приложение умеет импортировать его как кастомный сервер. Так что всё, что вы прочитаете ниже, применимо и к самостоятельной настройке, и к использованию готового сервиса.

Что такое WireGuard и почему он быстрый

WireGuard появился как ответ на «тяжесть» старых протоколов вроде OpenVPN и IPsec. Его философия — делать одно дело и делать его хорошо. Из этого вытекают все ключевые преимущества.

  • Маленький объём кода. Ядро WireGuard — это около 4 тысяч строк, тогда как OpenVPN с зависимостями — сотни тысяч. Меньше кода — меньше поверхность для ошибок и багов в безопасности, легче проводить аудит.
  • Современная криптография. WireGuard не даёт выбирать алгоритмы (как это делает OpenVPN). В нём жёстко зашит набор: ChaCha20 для шифрования, Poly1305 для аутентификации, Curve25519 для обмена ключами, BLAKE2s для хеширования. Нет «переговоров» о шифрах — нет целого класса атак на понижение.
  • Работа поверх UDP. Весь трафик идёт по UDP одним потоком. Это быстрее TCP-туннелей и не страдает от «TCP поверх TCP», когда два надёжных транспорта мешают друг другу.
  • Stateless-дизайн. Сервер не держит тяжёлых сессий. Если пакет не подходит ни под один валидный ключ — он просто молча отбрасывается. Снаружи открытый порт WireGuard почти не отвечает на сканирование, что делает сервер «тихим».
  • Быстрый роуминг. Соединение привязано к криптографическим ключам, а не к IP-адресу. Когда телефон переключается с Wi-Fi на мобильную сеть, туннель не рвётся — следующий пакет просто приходит с нового адреса, и сервер обновляет endpoint.

Цена за эту скорость — узнаваемый «почерк» трафика. К теме обхода DPI мы вернёмся ниже.

Как это работает: ключи, пиры и рукопожатие

WireGuard построен на концепции пиров (peers). Нет жёсткого деления на «клиент» и «сервер» на уровне протокола — есть два узла, каждый из которых знает публичный ключ другого. То, что мы называем «сервером», — это просто пир со статичным внешним IP, к которому подключаются остальные.

Пары ключей

Каждый участник генерирует пару ключей Curve25519: приватный (хранится в секрете на устройстве) и публичный (передаётся другой стороне). Принцип такой же, как у SSH-ключей:

  • Свой приватный ключ вы указываете в своём конфиге.
  • Публичный ключ собеседника вы прописываете в секции его пира.

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

Рукопожатие (handshake)

Перед передачей данных стороны выполняют рукопожатие по схеме Noise (Noise_IKpsk2). В ходе него вырабатываются временные симметричные ключи для сессии. Рукопожатие повторяется примерно раз в 2 минуты, чтобы обеспечить forward secrecy — даже если ключ сессии когда-то утечёт, прошлый трафик расшифровать не выйдет. Если в статусе wg show вы видите свежий latest handshake — туннель живой; если рукопожатия нет, соединение не установилось.

Криптороутинг

Главная идея WireGuard — cryptokey routing. Каждому пиру сопоставлен список AllowedIPs. Эта таблица работает в обе стороны:

  • На приём: пакет принимается, только если его адрес-источник попадает в AllowedIPs того пира, чьим ключом он зашифрован. Иначе — отбрасывается.
  • На отправку: когда нужно отправить пакет на некий IP, WireGuard ищет пира, в чьём AllowedIPs этот адрес есть, и шлёт через него.

То есть AllowedIPs — это одновременно и список разрешённых адресов, и таблица маршрутизации.

Разбор конфига по полям

Конфиг WireGuard — это простой ini-файл из двух типов секций: одна [Interface] (это «я») и одна или несколько [Peer] (это «они»). Вот аннотированный пример клиентского конфига:

[Interface]
# Приватный ключ ЭТОГО устройства (никому не показывать)
PrivateKey = PRIVATE_KEY_HERE
# Внутренний адрес этого устройства в VPN-подсети
Address = 10.7.0.2/32
# DNS-серверы, которые использовать при активном туннеле
DNS = 1.1.1.1, 1.0.0.1
# Подгонка MTU (опционально, см. раздел про MTU)
MTU = 1420

[Peer]
# Публичный ключ СЕРВЕРА
PublicKey = SERVER_PUBLIC_KEY_HERE
# Необязательный пресхаред-ключ для пост-квантовой устойчивости
PresharedKey = PRESHARED_KEY_HERE
# Куда подключаться: внешний IP/домен сервера и UDP-порт
Endpoint = vpn.example.com:51820
# Какой трафик заворачивать в туннель (0.0.0.0/0 = весь)
AllowedIPs = 0.0.0.0/0, ::/0
# Слать «пустые» пакеты раз в 25с, чтобы держать NAT открытым
PersistentKeepalive = 25

Разберём поля:

  • PrivateKey — приватный ключ этого узла. Это единственный по-настоящему секретный элемент конфига.
  • Address — внутренний адрес в VPN-сети. Маска /32 означает «только этот адрес». Сервер обычно 10.7.0.1/24, клиенты — 10.7.0.2/32, 10.7.0.3/32 и так далее.
  • DNS — какие DNS-серверы прописать, пока туннель активен. Критично для защиты от DNS-утечек (об этом ниже).
  • MTU — размер пакета; иногда требует тюнинга.
  • PublicKey (в [Peer]) — публичный ключ собеседника.
  • PresharedKey — необязательный общий секрет, добавляющий симметричный слой поверх асимметрии. Полезен как страховка против будущих квантовых атак.
  • Endpoint — адрес и порт, куда слать пакеты. У клиента он указывает на сервер; у сервера для клиента обычно не указывается (клиент сам приходит, и сервер запоминает его адрес).
  • AllowedIPs — на клиенте 0.0.0.0/0, ::/0 означает «весь трафик через VPN». Если указать только 10.7.0.0/24, в туннель пойдёт лишь трафик к VPN-подсети (режим split-tunnel).
  • PersistentKeepalive — интервал служебных пакетов для удержания NAT-сессии. Нужен пирам за NAT.

Поднимаем свой WireGuard-сервер

Ниже — концептуальные шаги, не привязанные к конкретному дистрибутиву. Команды wg и wg-quick одинаковы везде; различается только установка пакета и менеджер фаервола.

Шаг 1. Установка и генерация ключей

Поставьте пакет (wireguard или wireguard-tools) и сгенерируйте ключи на сервере:

# Создаём пару ключей сервера
wg genkey | tee server_private.key | wg pubkey > server_public.key

# И заодно для первого клиента
wg genkey | tee client1_private.key | wg pubkey > client1_public.key

# (опционально) общий пресхаред-ключ
wg genpsk > client1_preshared.key

wg genkey создаёт приватный ключ, wg pubkey выводит соответствующий публичный. Храните приватные ключи строго (chmod 600).

Шаг 2. Конфиг сервера wg0.conf

Создайте /etc/wireguard/wg0.conf:

[Interface]
Address = 10.7.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY_HERE
# Включаем NAT при поднятии интерфейса и убираем при остановке
PostUp = iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE

[Peer]
# Первый клиент
PublicKey = CLIENT1_PUBLIC_KEY_HERE
PresharedKey = CLIENT1_PRESHARED_KEY_HERE
AllowedIPs = 10.7.0.2/32

Обратите внимание: на стороне сервера в AllowedIPs пира стоит конкретный адрес клиента (10.7.0.2/32), а не 0.0.0.0/0. Сервер должен знать, какому пиру принадлежит какой внутренний адрес. Замените eth0 на имя своего внешнего сетевого интерфейса.

Шаг 3. Включаем форвардинг и NAT

Чтобы сервер пересылал трафик клиентов в интернет, включите IP-форвардинг:

# Временно
sysctl -w net.ipv4.ip_forward=1
# Постоянно — добавьте в /etc/sysctl.conf:
# net.ipv4.ip_forward = 1

Правило MASQUERADE из PostUp подменяет внутренние адреса 10.7.0.x на внешний IP сервера — это и есть NAT, благодаря которому ответы возвращаются правильному клиенту.

Шаг 4. Открываем UDP-порт и запускаем

WireGuard слушает UDP, по умолчанию порт 51820. Откройте его в фаерволе/у облачного провайдера, затем поднимите интерфейс:

# Разрешаем порт (пример для ufw)
ufw allow 51820/udp

# Поднимаем туннель и ставим в автозапуск
wg-quick up wg0
systemctl enable wg-quick@wg0

# Проверяем статус
wg show

wg-quick — обёртка, которая читает конфиг, поднимает интерфейс, прописывает маршруты и выполняет PostUp. Команда wg show покажет пиров, их последнее рукопожатие и счётчики трафика.

Шаг 5. Добавляем новых клиентов

Чтобы добавить ещё одного пользователя: сгенерируйте ему пару ключей, добавьте новую секцию [Peer] в wg0.conf (с уникальным AllowedIPs, например 10.7.0.3/32) и примените изменения без разрыва текущих соединений:

wg syncconf wg0 <(wg-quick strip wg0)

Клиентские конфиги и подключение

Под каждое устройство создаётся свой конфиг по образцу из раздела «Разбор конфига». Главное — у каждого клиента свой приватный ключ и уникальный Address.

  • Десктоп (Windows/macOS/Linux). Установите официальный клиент WireGuard, импортируйте .conf и нажмите «Connect». Под Windows удобно использовать готовое приложение — см. наш гид VPN для Windows. Свой конфиг можно вставить бесплатно в клиент GANVAS для своего конфига — один клиент для WireGuard, VLESS и Tor.
  • Телефон. В мобильном приложении WireGuard добавьте туннель сканированием QR-кода. QR генерируется из конфига:
# Превратить конфиг в QR прямо в терминале
qrencode -t ansiutf8 < client1.conf
  • Роутер. Многие прошивки (OpenWrt, последние версии популярных роутеров) поддерживают WireGuard нативно — тогда весь домашний трафик идёт через туннель без настройки каждого устройства.

После подключения проверьте реальную скорость нашим тестом скорости и убедитесь, что внешний IP сменился на адрес сервера.

Тюнинг MTU и проблемы за NAT

Зачем нужен MTU

WireGuard добавляет к каждому пакету свой заголовок, поэтому полезная нагрузка внутри туннеля меньше, чем в обычной сети. Если MTU выставлен слишком большим, пакеты начинают фрагментироваться или вовсе теряться — со стороны это выглядит как «интернет вроде есть, но сайты не грузятся» или «скорость странно низкая».

Типичное значение для WireGuard — 1420. Если канал использует PPPoE или другие туннели, безопаснее опуститься до 1280. Подобрать оптимум можно пингом с запретом фрагментации:

# Linux: ищем максимальный размер без фрагментации
ping -M do -s 1372 8.8.8.8
# Если "Frag needed" — уменьшайте -s, пока не пройдёт.
# Рабочий MTU = найденный размер + 28 (заголовки IP+ICMP)

Полученное значение поставьте в MTU секции [Interface].

PersistentKeepalive за NAT

Когда клиент сидит за домашним роутером (то есть за NAT), маршрутизатор держит «дырку» для UDP-сессии лишь пока по ней идут пакеты. В тишине эта дырка закрывается, и сервер больше не может достучаться до клиента — входящие соединения отваливаются. PersistentKeepalive = 25 отправляет крошечный пакет каждые 25 секунд, удерживая сессию живой. Для пира за NAT это практически обязательная настройка; для сервера со статичным IP — не нужна.

Частые проблемы

  • Нет рукопожатия (latest handshake пустой). Чаще всего — закрытый UDP-порт на фаерволе/у провайдера, неверный Endpoint или перепутанные ключи. Проверьте, что порт реально открыт и что публичный ключ сервера в клиенте совпадает.
  • Асимметричная маршрутизация. Сервер не знает обратного пути к клиенту — обычно из-за неверного AllowedIPs в секции пира на сервере. Каждому клиенту должен соответствовать его /32.
  • Рукопожатие есть, но интернета нет. Почти всегда это форвардинг (ip_forward) или забытое правило MASQUERADE. Реже — слишком большой MTU.

DNS и защита от утечек

Даже при поднятом туннеле возможна утечка: если DNS-запросы уходят мимо VPN, ваш провайдер всё равно видит, какие домены вы открываете. Поэтому в [Interface] обязательно задавайте DNS:

[Interface]
# ... остальные поля ...
DNS = 1.1.1.1, 1.0.0.1

wg-quick пропишет эти серверы как системные на время работы туннеля, и DNS-запросы пойдут внутри шифрованного канала. После подключения обязательно проверьтесь — подробно про механику мы писали в статье что такое DNS-утечка. Отдельно стоит проверить браузер: WebRTC умеет «выдавать» реальный IP в обход VPN — для этого есть наш инструмент WebRTC-тест.

WireGuard против OpenVPN и VLESS+Reality

У каждого протокола своя ниша.

  • WireGuard — лучший выбор по умолчанию: быстрый, лёгкий, экономит батарею, мгновенно переподключается. Идеален в сетях без жёсткого DPI.
  • OpenVPN — проверенная классика. Умеет работать по TCP/443 и лучше маскируется под HTTPS, но тяжелее и медленнее. Хорош для старых устройств и строгих корпоративных фаерволов.
  • VLESS+Reality — не совсем «VPN», а транспорт для обхода блокировок. Имитирует настоящее TLS-рукопожатие к крупному сайту, поэтому для DPI выглядит как обычный заход на популярный ресурс.

Полное сравнение по скорости и устойчивости — в статье WireGuard, OpenVPN или VLESS+Reality.

Когда WireGuard блокируют

Главная слабость WireGuard — узнаваемая сигнатура трафика. Системы глубокой инспекции пакетов (DPI) умеют опознавать характерный формат рукопожатия и просто резать UDP-поток, либо блокировать сам порт. Признаки блокировки: рукопожатие не проходит вообще или рвётся через несколько секунд после старта.

Что делать:

  • Сменить порт (иногда помогает уход с дефолтного 51820), хотя против сигнатурного DPI это слабая мера.
  • Завернуть WireGuard в обфускацию (например, udp2raw или WireGuard поверх обфусцирующего слоя).
  • Переключиться на протокол, заточенный под обход — VLESS+Reality. Подробности и стратегии — в гиде как обходить блокировки.

Безопасность: обращение с ключами

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

  • Приватный ключ не покидает устройство. Генерируйте пару прямо там, где она будет использоваться; передавайте по сети только публичный ключ.
  • Права на файлы. Конфиги с приватными ключами держите с правами 600 и владельцем root (chmod 600 /etc/wireguard/wg0.conf).
  • Один ключ — одно устройство. Не используйте один и тот же приватный ключ на нескольких устройствах: при компрометации одного придётся отзывать все.
  • Ротация ключей. Если устройство потеряно или вы подозреваете утечку — сгенерируйте новую пару, обновите секцию [Peer] на сервере и примените wg syncconf. Старый публичный ключ перестанет приниматься мгновенно.
  • PresharedKey как страховка. Добавление пресхаред-ключа защищает на случай будущих атак на асимметричную криптографию (в том числе квантовых) — это дешёвый дополнительный слой.

Как WireGuard использует GANVAS

GANVAS VPN использует WireGuard как один из основных протоколов на своих серверах — именно за скорость, экономичность и мгновенный роуминг. Когда сеть «чистая», приложение по умолчанию идёт через WireGuard; когда включается жёсткий DPI, оно автоматически предлагает VLESS+Reality или Tor-режим.

И главное для тех, кто прошёл всю эту статью: ваш собственный WireGuard-конфиг работает в приложении бесплатно. Сгенерировали пару ключей, подняли сервер, импортировали .conf как кастомный сервер — и пользуетесь своей инфраструктурой через удобный клиент с защитой от утечек. Никакой подписки для своих конфигов не требуется — подробности в разделе бесплатный VPN, а сравнение тарифов и возможностей — на странице сравнения.

Хотите готовые серверы без возни с конфигами — просто попробуйте GANVAS VPN. Хотите полный контроль — поднимите свой WireGuard по этому гиду и подключите его к тому же приложению. Оба пути ведут к быстрому и приватному соединению.