WireGuard на своём сервере: настройка VPN

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

Кому подходит свой WireGuard

Свой WireGuard уместен для удалённого доступа к домашней сети, админским панелям, тестовым стендам и рабочим сервисам. Ограничение сразу: это не кнопка приватности. Владелец VPS видит факт подключения, датацентр получает жалобы на злоупотребления, а ошибки маршрутизации остаются вашими.

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

Как выбрать VPS под WireGuard

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

Таблица не назначает победителя по минимальной цене. Для WireGuard на телефоне и ноутбуке младшего VPS обычно достаточно, но запас RAM полезен для обновлений, журналов и дополнительных служб. Для корпоративного доступа лучше отделить VPN от сайтов и баз данных.

Установка на Ubuntu

Ниже базовый сценарий для чистого Ubuntu Server. Он не привязан к конкретному хостеру: вам нужен root-доступ, публичный адрес сервера и открытый UDP-порт. Не берите тариф, который даёт только красивую панель без полноценного доступа к системе.

sudo apt update
sudo apt install wireguard
wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key
sudo chmod 600 /etc/wireguard/server_private.key

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

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

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

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sudo systemctl enable --now wg-quick@wg0
sudo wg show

Добавление клиента

Клиент в WireGuard — это не учётная запись с паролем, а отдельная пара ключей и свой адрес в туннеле. Не раздавайте один конфиг всем устройствам: при компрометации вы не поймёте, кого отключать, и получите конфликты адресов.

На сервере подготовьте публичный ключ клиента и добавьте peer. На клиентском устройстве приватный ключ остаётся только у клиента.

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

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

[Interface]
Address = 10.8.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = SERVER_PUBLIC_IP:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Что проверить после первого подключения

• Handshake должен обновляться после подключения клиента, иначе проверьте порт, публичный адрес и ключи.
• Маршрут по умолчанию нужен только для полного VPN, иначе клиент может увести через туннель лишний трафик.
• DNS должен идти через выбранный резолвер, иначе браузер продолжит светить запросы вне туннеля.
• Доступ по SSH лучше держать отдельным правилом, чтобы ошибка в WireGuard не закрыла аварийный вход.

Где чаще всего ломается настройка

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

Вторая ошибка — закрытый UDP у провайдера, в панели брандмауэра или в самой системе. WireGuard работает поверх UDP, поэтому TCP-проверка порта не доказывает, что туннель доступен. Проверяйте именно UDP и журнал интерфейса, а не только статус службы.

Третья ошибка — конфликт подсетей. Если домашний роутер, офисная сеть и WireGuard используют один диапазон, маршруты становятся непредсказуемыми. Возьмите непересекающуюся приватную подсеть и зафиксируйте её в документации проекта. Self-hosting как дача зимой: забытая мелочь потом требует выезда в неудобный момент.

Когда лучше не поднимать свой VPN

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

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

Как мы поддерживаем актуальность

В тарифных примерах используются поля, которые HostScout регулярно пересобирает из карточек провайдеров и прайс-листов. Для гайда важны не только цены: мы отдельно смотрим на локации, тип диска, объём RAM, доступность VPS и пригодность тарифа для самостоятельного администрирования.