Прямой ответ
WireGuard — современный VPN-протокол: ~4000 строк кода ядра (аудитируемость против десятков тысяч у OpenVPN/IPsec), современная криптография (Noise, Curve25519, без унаследованных алгоритмов), и настройка, которая укладывается в один файл на клиента. Для разработчика он закрывает три задачи: приватный доступ к своим серверам (админка, БД, метрики не торчат в интернет — доступны только из VPN), доступ к домашней сети извне (dev-сервер, NAS, лаборатория — без проброса портов наружу), безопасный трафик в чужих сетях (кафе/отели — весь трафик через свой VPS). Поднятие сервера — десять минут на свежем VPS (пакет wireguard, ключи, systemd-юнит), клиент — конфиг-файл или QR-код в мобильное приложение. Важно понимать границу: WireGuard шифрует и туннелирует, но не анонимизирует — ваш VPS видит весь трафик; для «полной анонимности» это не инструмент, для приватности и доступа — именно он.
Как это устроено: ключи, пиры, адреса
Модель радикально проще классических VPN: нет сервера и клиентов как ролей — есть пиры (peers), у каждого пара ключей (приватный остаётся у владельца, публичный раздаётся остальным) и IP-адрес внутри туннельной сети (10.0.0.0/24 — ваша воображаемая локалка). Пир знает публичные ключи и адреса тех, с кем говорит; соединение устанавливается при первом пакете (никаких «логина/пароля» — аутентификация криптографическая). Следствия: добавление клиента — добавить блок [Peer] с его публичным ключом на сервере и раздать клиенту конфиг; отзыв — удалить блок (или поменять ключи пира); NAT проходится автоматически (keepalive-пакеты). Приватный ключ — полноценный секрет (правила хранения): компрометация ключа = доступ в вашу сеть, лечится только перевыпуском.
Сервер на VPS: полный рецепт
Установка: apt install wireguard → wg genkey | tee private.key | wg pubkey > public.key → конфиг /etc/wireguard/wg0.conf: [Interface] с приватным ключом сервера, Address = 10.0.0.1/24, ListenPort = 51820, и PostUp/PostDown с iptables-правилами (включая MASQUERADE, если клиентам нужен выход в интернет через сервер). [Peer]-блок на каждого клиента: его публичный ключ и AllowedIPs = 10.0.0.2/32 (какие адреса принадлежать этому пиру). Включение — systemctl enable --now wg-quick@wg0 (systemd-юнит из пакета; устройство wg0 поднимается при загрузке — устройство юнитов в статье про systemd). На стороне облака — security group/файрвол: открыть 51820/udp. Всё — сервер работает; проверка с клиента — ping 10.0.0.1.
Клиенты и два режима использования
Конфиг клиента — зеркало: свой приватный ключ, Peer с публичным ключом сервера, Endpoint = vps-ip:51820, и главное — AllowedIPs, определяющий, какой трафик идёт в туннель. Режим «только своя сеть»: AllowedIPs = 10.0.0.0/24, 192.168.1.0/24 — в VPN уходят только адреса лаборатории, остальной трафик — как обычно (типичный рабочий режим). Режим «весь трафик»: AllowedIPs = 0.0.0.0/0 (+ ::/0) — через сервер идёт всё (приватность в чужих сетях). Мобильные клиенты (официальные приложения) генерируют ключи на устройстве и принимают конфиг QR-кодом (qrencode -t ansiutf8 < client.conf) — приватный ключ не покидает телефон. Десктоп — wg-quick up client.conf или интеграция в NetworkManager/systemd. Комбинация с SSH: доступ к серверам — только по туннельному адресу (sshd слушает 10.0.0.1 или файрвол пускает 22 только с VPN-подсети) — публичный 22-й порт закрывается вовсе, и брутфорс-сканеры интернета перестают существовать как фактор (сравнение с чистыми SSH-туннелями — в статье про туннели и port-forwarding).
Практический сценарий: домашняя лаборатория + доступ извне
Задача: дома стоит сервер с dev-окружением (БД, Grafana, git), нужно работать из любого места без единого проброшенного порта. Схема: на домашнем сервере — WireGuard-клиент с keepalive к пиру на VPS или прямой peer-to-peer (если у домашней сети белый IP); второй пир — ноутбук. На ноутбуке конфиг с AllowedIPs = 10.0.0.0/24 — и (Grafana),ssh deploy@10.0.0.10`, git-remote по туннельному адресу работают из кафе так же, как из дома. На домашнем сервере файрвол — default deny извне, всё управление только через VPN-интерфейс. Добавление телефона — минута (QR); отзыв потерянного устройства — удаление пира. Через месяц эксплуатации становится заметно главное: «доступ к домашним сервисам» перестал быть отдельной задачей безопасности — нет портов наружу, нет VPN-дыр в конфиге роутера, есть один криптографический вход и полный контроль над списком устройств.
Диагностика и типовые проблемы
Порядок проверок при «не работает»: wg show на обеих сторонах (есть ли latest handshake — нет: UDP не проходит, файрвол/NAT; есть, но пинга нет: адреса/AllowedIPs); ip addr (поднялся ли wg0); на сервере — sysctl net.ipv4.ip_forward=1 (без forwarding сервер не маршрутизирует трафик клиентов — для режима «весь трафик через сервер» обязательно) и iptables MASQUERADE; логи — journalctl -u wg-quick@wg0. Типовое: корпоративные сети блокируют исходящий UDP 51820 (лечение — нестандартный порт на сервере); мобильный оператор за строгим NAT (keepalive 25 с на клиенте); «работало и отвалилось» — сменился IP у пира за динамическим NAT (endpoint обновляется по incoming-пакетам; при симметричном NAT нужен посредник с белым IP — роль VPS). MTU-проблемы (сайты «зависают» в туннеле) — снизить MTU интерфейса (1420 — типовой дефолт WireGuard).
FAQ
WireGuard или OpenVPN? Для личных и командных задач — WireGuard: проще, быстрее, современнее криптография. OpenVPN остаётся для совместимости с легаси и сценариев с аутентификацией по сертификатам/учёткам (в WireGuard управление доступом — только ключами, что при сотнях пользователей требует обвязки).
Законно ли поднимать свой VPN? В большинстве юрисдикций свой VPN для доступа к своим ресурсам — стандартная практика; ограничения касаются обходных сервисов и местных норм — проверьте законодательство страны проживания/пребывания перед настройкой «весь трафик через VPS».
Как дать доступ коллеге и потом забрать?
Выпустить ему отдельную пару ключей (его приватный — у него), добавить Peer-блок с его AllowedIPs; отзыв — удалить блок и wg syncconf wg0 <(wg-quick strip wg0). Ключи не переиспользовать между людьми — иначе отзыв одного не работает.
Нужен ли VPN, если всё уже по SSH? SSH-туннели решают точечный проброс портов; VPN даёт «целую сеть как локальную» — все сервисы сразу, UDP-трафик, удобство для не-SSH-протоколов (метрики, веб-админки, базы). Часто достаточно SSH — тогда VPN избыточен; при трёх и более сервисах VPN удобнее.
Источники: wireguard.com (протокол, quickstart), man wg-quick — ссылки в шапке.