Такой порядок позволяет понять, работают ли ключи и доступность UDP, прежде чем добавлять маршрутизацию, NAT и DNS. Если нужен готовый личный VPN без самостоятельной работы с Linux, можно использовать установку через Amnezia либо обсудить настройку с @tumbler3.

Условия примера

Понадобятся отдельный поддерживаемый Ubuntu-сервер, административный доступ, публичный IPv4 и клиент с официальным WireGuard. Пример рассчитан на человека, который умеет редактировать системный файл и понимает различие между сервером и своим компьютером. Команды ниже выполняются на сервере, если явно не сказано другое.

Используем внутреннюю сеть 10.77.77.0/24: серверу назначим 10.77.77.1, клиенту — 10.77.77.2. До начала проверьте, что она не пересекается с вашими существующими сетями. Если пересекается, согласованно замените адреса во всех примерах.

Порт примера — UDP 51820. Он должен быть свободен и разрешён правилами хостинга и сервера. Открытие TCP с тем же номером не заменяет UDP. Сохраните рабочий SSH-доступ и возможность открыть консоль хостинга.

Установите инструменты и создайте ключи сервера

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

На сервере обновите список пакетов и установите официальный пакет:

sudo apt update
sudo apt install wireguard

Создайте закрытый каталог для ключей и сгенерируйте пару. В блоке используется административная оболочка; завершите её командой exit после работы.

sudo -i
install -d -m 700 /etc/wireguard
cd /etc/wireguard
umask 077
wg genkey > server.key
wg pubkey < server.key > server.pub
exit

Закрытый ключ из server.key остаётся секретным на сервере. Открытый из server.pub понадобится клиенту. Не публикуйте полный конфигурационный файл в вопросе на форуме: в нём может находиться закрытый ключ.

Создайте отдельную пару ключей клиента

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

Если клиент на Linux настраивается через командную строку, пару можно создать теми же командами wg genkey и wg pubkey на самом клиентском устройстве. Не используйте одну пару для сервера и клиента. У каждого участника свои реквизиты.

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

Серверный файл wg0.conf

Создайте /etc/wireguard/wg0.conf через sudoedit /etc/wireguard/wg0.conf. Замените метки реальными значениями. Слово SERVER_PRIVATE_KEY в готовом файле оставаться не должно.

[Interface]
Address = 10.77.77.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.77.77.2/32

Здесь сервер принимает от данного клиента его отдельный внутренний адрес. Не подставляйте на сервере 0.0.0.0/0 вместо адреса клиента по аналогии с чужой инструкцией полного туннеля. Роли параметра в конкретной схеме нужно сохранять.

Ограничьте доступ к файлу:

sudo chmod 600 /etc/wireguard/wg0.conf

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

Клиентская конфигурация

В клиенте используйте его собственный приватный ключ, публичный ключ сервера и реальный публичный IPv4 VPS:

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.77.77.2/32

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = SERVER_PUBLIC_IPV4:51820
AllowedIPs = 10.77.77.1/32

Endpoint — внешний адрес сервера, а не 10.77.77.1. Внутренний адрес доступен уже через туннель. Здесь нет DNS и маршрута всего интернета: это намеренно ограниченная проверка связи с сервером.

Не добавляйте PersistentKeepalive автоматически ради «ускорения». Этот параметр применяют при соответствующей задаче сохранения отображения NAT; он не исправляет неверные ключи и не снижает задержку сам по себе.

Разрешите нужный порт и запустите интерфейс

В сетевых правилах хостинга разрешите входящий UDP 51820 для нужного сценария. Если на сервере уже используется UFW, проверьте его состояние и добавьте точечное правило:

sudo ufw status
sudo ufw allow 51820/udp

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

Запустите туннель и посмотрите состояние:

sudo wg-quick up wg0
sudo wg show wg0

Затем активируйте клиент. Для проверки отправьте с него трафик к 10.77.77.1, например ping, если ICMP разрешён. Само отсутствие ответа ping при фильтрации ещё не доказывает отсутствие туннеля.

Как читать результат проверки

В выводе wg show wg0 смотрите время последнего handshake и счётчики передачи. Свежий handshake после клиентского запроса подтверждает обмен между участниками, но не настройку выхода в интернет. Рост счётчиков помогает увидеть активность.

Если handshake нет, последовательно сверяйте внешний адрес, UDP-порт, ключи и правила сети. Если он есть, но внутренний адрес недоступен, проверяйте адреса, AllowedIPs и фильтрацию. Не меняйте все параметры одновременно.

Чтобы остановить интерфейс на сервере, выполните sudo wg-quick down wg0. После успешной ручной проверки можно включить запуск при старте системы командой sudo systemctl enable wg-quick@wg0 и затем отдельно проверить восстановление после запланированной перезагрузки.

Что нужно для интернета через сервер

Следующий этап включает пересылку пакетов, правила выхода и обратного трафика, обычно NAT для частной IPv4-сети, клиентские маршруты и DNS. Простая замена AllowedIPs на весь интернет без серверной части может оставить клиента без доступа.

В официальной документации Ubuntu есть отдельная схема VPN как шлюза. Применяйте её с фактическим внешним интерфейсом и существующими правилами вашего VPS. IPv6 и поведение при отключении туннеля проверяются отдельно.

Не называйте первый успешный handshake готовой защитой всего устройства. Критерий этого этапа скромнее и точнее: клиент и сервер обмениваются данными внутри заданного туннеля. После этого расширять схему значительно проще.

Отзыв тестового доступа

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

Для проверки имён после настройки полного выхода используйте разбор DNS и VPN. Успешный ответ внутреннего адреса не подтверждает работу разрешения имён.

Вопросы и ответы

Почему после настройки внешний IP не изменился?

Пример направляет через туннель только внутренний адрес сервера. Для выхода всего интернета нужны дополнительные маршруты, пересылка, правила сети и DNS.

Можно один ключ использовать для всех устройств?

Для управляемой схемы создавайте отдельную пару и адрес каждому устройству. Это позволяет различать участников и отзывать конкретный доступ.

Открытый TCP 51820 подходит?

WireGuard передаёт пакеты по UDP. Правило для TCP с тем же номером не разрешает нужный UDP-трафик.

Handshake есть, значит всё готово?

Он подтверждает обмен ключами между участниками. Доступ к сервисам, маршрутизация, DNS и полный выход в интернет проверяются отдельно.

Настройка доступа: инструкции Тумблера. Вопросы по подключению можно задать поддержке.