Настройка сервера WireGuard требует больше, чем недавнее рукопожатие. Здесь создается IPv4-шлюз на Ubuntu 24.04 LTS с отдельным клиентом Ubuntu 24.04 LTS. Затем отдельно проверяются пересылка, DNS, отказ, отзыв, перезагрузка и восстановление.

Используйте выделенные собственные или разрешенные узлы. Команды предназначены читателю, а не описывают выполненное автором развертывание.

Ключевые выводы

Соединение пиров не подтверждает интернет-пересылку и работу DNS.

Сохраните независимое управление и восстановимую основу межсетевого экрана.

Пример ограничен IPv4; альтернативный IPv6-путь требует отдельной работы.

Отзыв удаляет пир и из работающего интерфейса, и из постоянного файла.

Автозапуск включается после ограниченной задачи и проверки восстановления.

Нужна ли вам настройка сервера WireGuard или обслуживаемый выход?

Руководство самостоятельного размещения помогает назначить владельца узла, учетных данных, обновлений и завершения работы. Для одного приложения с явной настройкой прокси развертывание VLESS/REALITY представляет другой путь, а не предварительный шаг. Полный туннель и прокси приложения объясняют различие охвата.

Если нужен повседневный публичный доступ без обслуживания пиров, AethoVPN предлагает путь для поддерживаемого устройства. На Windows установите официальный .exe, продолжите с кодом подтверждения электронной почты, выберите реально доступное расположение в App и подключитесь. Проверьте видимый выход запроса инструментом проверки выходного IP, затем повторите исходную задачу браузера или загрузки.

До аренды сравните обязанности VPS и VPN. Standard поддерживает одно мобильное устройство; Pro — два настольных и два мобильных; Premium — восемь устройств без разделения типов.

Этот способ не создает ваш сервер и не обещает совместимость с показанной конфигурацией WireGuard. Новый пользователь получает один трехдневный пробный Pro; удаление и повторное создание учетной записи не дает его заново. Попробовать обслуживаемый повседневный выход.

Подготовьте сервер WireGuard на Ubuntu и восстановление

Нужны выделенный Ubuntu 24.04 LTS с достижимым публичным IPv4 endpoint и отдельный разрешенный Ubuntu-клиент. Узлу за NAT дополнительно требуется разрешенное отображение UDP на вышестоящем оборудовании; одного частного адреса недостаточно.

Зарезервируйте UDP 51820, диапазон 10.77.0.0/24, сервер 10.77.0.1 и клиент 10.77.0.2. При пересечении с существующими сетями замените диапазон. Модель пиров WireGuard объясняет роли сторон.［1］

До изменений запишите ip address, ip route, ip rule, ip -6 address, ip -6 route, resolvectl status, sysctl net.ipv4.ip_forward и относящиеся к задаче правила. Храните записи частным образом.

Через независимую консоль провайдера или путь восстановления установите новое соединение управления. Уже открытый терминал не подтверждает это свойство. Сохраните исходные файлы вне публичных репозиториев.

Пример правил использует iptables без конкурирующего UFW, firewalld или независимого менеджера nftables. Изучите sudo iptables-save и владельца политики. Если правила принадлежат другому менеджеру, остановитесь и реализуйте ту же узкую политику через него. Никогда не очищайте таблицы.

Найдите действительный выходной интерфейс сервера через ip -4 route get 1.1.1.1: команда показывает выбор маршрута, не отправляя пробный пакет. EGRESS_IF ниже — заменяемое значение, а не имя реального интерфейса.

Выберите управляемый клиент без пригодного IPv6-маршрута по умолчанию. Если исходная проверка показывает такой маршрут, остановите упражнение IPv4 и отдельно спроектируйте IPv6 и поведение отказа. Не отключайте IPv6 на общем узле ради красивого результата. Пример также не содержит kill switch: после остановки туннеля возвращается обычная маршрутизация.

На схеме отделены туннель, пересылка/NAT сервера и публичное назначение. Управление должно пережить отказ туннеля. Это объяснение топологии, а не измеренные данные трафика.

Шаг 1: Установите инструменты и отдельные ключи

Установите пакеты на обеих машинах из настроенных доверенных репозиториев Ubuntu. Проект указывает установку Ubuntu через apt.［2］

sudo apt update
sudo apt install wireguard iptables
sudo install -d -m 700 /etc/wireguard
sudo -i
cd /etc/wireguard
umask 077
wg genkey > wg-exit.private
wg pubkey < wg-exit.private > wg-exit.public
exit

Генерируйте ключи независимо на каждой стороне. Закрытый ключ остается на своем узле, передается только соответствующий открытый ключ.［1］

Файлы должны принадлежать root и иметь закрытые разрешения. Не публикуйте рабочие профили, QR-коды, снимки или значения ключей. Названия ниже обозначают подстановки, не готовые секреты. До добавления пира запишите устройство, которому принадлежит открытый ключ.

Шаг 2: Включите пересылку и межсетевой экран WireGuard

Частным редактором создайте серверный /etc/wireguard/wg-exit.conf, подставив ключ и EGRESS_IF. Эти hook-правила имеют отличительную метку и предназначены одному клиенту. wg-quick выполняет их при изменении состояния интерфейса.［3］

[Interface]
Address = 10.77.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = iptables -I INPUT 1 -p udp --dport 51820 -m comment --comment wg-exit-lab -j ACCEPT
PostUp = iptables -I FORWARD 1 -i %i -o EGRESS_IF -s 10.77.0.2/32 -m comment --comment wg-exit-lab -j ACCEPT
PostUp = iptables -I FORWARD 1 -i EGRESS_IF -o %i -d 10.77.0.2/32 -m conntrack --ctstate ESTABLISHED,RELATED -m comment --comment wg-exit-lab -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.77.0.2/32 -o EGRESS_IF -m comment --comment wg-exit-lab -j MASQUERADE
PreDown = iptables -D INPUT -p udp --dport 51820 -m comment --comment wg-exit-lab -j ACCEPT
PreDown = iptables -D FORWARD -i %i -o EGRESS_IF -s 10.77.0.2/32 -m comment --comment wg-exit-lab -j ACCEPT
PreDown = iptables -D FORWARD -i EGRESS_IF -o %i -d 10.77.0.2/32 -m conntrack --ctstate ESTABLISHED,RELATED -m comment --comment wg-exit-lab -j ACCEPT
PreDown = iptables -t nat -D POSTROUTING -s 10.77.0.2/32 -o EGRESS_IF -m comment --comment wg-exit-lab -j MASQUERADE

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.77.0.2/32

Разрешите тот же UDP-порт в группе безопасности провайдера, сохранив управление. Если публичный источник клиента стабилен, ограничьте им INPUT и облачное правило. При добавлении -s CLIENT_PUBLIC_IPV4/32 включите условие и в установку, и в удаление правила. Группа безопасности и межсетевой экран узла являются разными слоями.

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

NAT обеспечивает публичный обратный путь, но не разрешает другого пира. Ubuntu документирует forwarding и masquerading для интернет-шлюза.［4］

sudo chmod 600 /etc/wireguard/wg-exit.conf
sudo chown root:root /etc/wireguard/wg-exit.conf

Запишите прежнее значение forwarding и убедитесь, что путь свободен. Затем создайте отдельный /etc/sysctl.d/70-wg-exit.conf с net.ipv4.ip_forward=1. Применяйте только этот файл:

sudo sysctl -p /etc/sysctl.d/70-wg-exit.conf
sudo wg-quick up wg-exit
sudo wg show wg-exit

При частичном отказе hook перед повтором проверьте интерфейс и правила. Удаляйте остатки только точно соответствующими командами удаления: повторная вставка создает дубликаты. Не добавляйте SaveConfig=true; руководство предупреждает о перезаписи файла работающим состоянием при выключении.［3］

Шаг 3: Интернет-шлюз WireGuard и DNS клиента

Создайте частный клиентский /etc/wireguard/wg-exit.conf:

[Interface]
Address = 10.77.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
PostUp = resolvectl dns %i AUTHORIZED_DNS_IPV4
PostUp = resolvectl domain %i ~.
PreDown = resolvectl revert %i

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

Подставьте публичный endpoint и доступный DNS-резолвер, которым разрешено пользоваться. Установите владельца root и режим 600, затем выполните sudo wg-quick up wg-exit.

AllowedIPs влияет на маршрутизацию и адреса пира; серверный /32 и клиентский маршрут по умолчанию выполняют разные роли. Перед изменением прочитайте руководство AllowedIPs. При default route wg-quick применяет policy routing: смотрите ip rule и соответствующие таблицы, не только main.［3］

Ubuntu systemd-resolved позволяет настраивать DNS интерфейса и routing domain ~. через resolvectl.［5］ Здесь намеренно отсутствует DNS=, потому что wg-quick передает его resolvconf. До применения hooks подтвердите фактическое использование systemd-resolved клиентом.

Зашифрованный DNS внутри приложения требует отдельной проверки. Keepalive помогает некоторым NAT-сопоставлениям, а не увеличивает скорость; при отсутствии необходимости его можно убрать.［1］

Шаг 4: Проверьте, отзовите, перезапустите и восстановите

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

Проверка	Метод	Ожидаемый результат	При отказе
Интерфейс и пир	С обеих сторон: `sudo wg show wg-exit` и `ip -4 address show dev wg-exit`［6］	Нужная пара ключей; сервер `10.77.0.1/24`, клиент `10.77.0.2/32`	Исправить владельцев до маршрутов
Аутентификация	Разрешенный запрос и время handshake	Новое рукопожатие после запроса	Проверить UDP и ключи
Данные и выход	Повторить разрешенную публичную задачу, сравнить счетчики и выход	Счетчики растут, виден нужный выход	Проверить forwarding, NAT, ответ
DNS	`resolvectl status wg-exit`; `resolvectl query TASK_HOST`	Нужный интерфейс/резолвер и ответ	Исправить область DNS, проверить приложение
IPv6	Повторить проверку адресов и маршрутов	Нет пригодного альтернативного пути	Прекратить IPv4-приемку
Невыданный пир	Новый одноразовый ключ вне серверного списка	Нет аутентифицированной связи и пересылки	Закрыть экспозицию, проверить список
Отзыв	Удалить рабочий и постоянный пир, повторить трафик	Нет новой аутентификации или продолжения данных	Найти воссоздающий источник

Для отзыва используйте действительный открытый ключ устройства:

sudo wg set wg-exit peer CLIENT_PUBLIC_KEY remove

Затем удалите блок этого пира из серверного файла. Не сохраняйте всю работающую конфигурацию поверх hooks. Повторите попытку удаленным клиентом и изучите действующий список сервера.

Для последующего разрешенного теста выдайте новые данные. Удаление профиля на клиенте не отзывает серверное разрешение.

Верните разрешенный одноразовый пир и завершите проверки, затем включите запуск на каждом выделенном узле:

sudo systemctl enable wg-quick@wg-exit.service

Перезагружайте только разрешенный узел. После загрузки проверьте systemctl status wg-quick@wg-exit.service, wg show, forwarding, точные правила, область резолвера и новый запрос задачи. Перезапуск контейнера не заменяет жизненный цикл хоста. Если перезагрузка недоступна, оставьте эту строку непроверенной.

Отказы и обслуживание

Отсутствие handshake сначала указывает на ключи, endpoint, вход или фильтрацию UDP. Handshake без ответа задачи требует следующей проверки маршрута клиента, forwarding, NAT и обратной политики. Рабочий IP-запрос при отказе имен направляет к DNS.

Следуйте списку проверки соединения без интернета, меняя один слой и повторяя ту же задачу. Работоспособность другого VPN не локализует этот отказ.

Поддерживайте ПО, выдавайте отдельный пир каждому независимо отзываемому устройству и повторяйте отказ и восстановление после существенных изменений. Записывайте также изменения сети провайдера. Остановитесь, если не можете объяснить правило, теряете независимое управление или требуется менять общую производственную политику.

Возврат к исходной основе

На клиенте выполните sudo wg-quick down wg-exit и отключите автозапуск, если включали его. На сервере для действующего управляемого unit используйте sudo systemctl disable --now wg-quick@wg-exit.service; для вручную поднятого интерфейса — sudo wg-quick down wg-exit. Сначала установите фактическое состояние: отключение неактивного unit не удаляет ручной интерфейс.

После неудачного hook найдите остатки и удалите только точные записи эксперимента. Уберите также собственное облачное правило.

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

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

Итоги

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

Часто задаваемые вопросы (FAQ)

Требуется ли публичный сервер?

Для задачи интернет-выхода нужен разрешенный достижимый endpoint. Узлу за NAT требуется подходящее отображение выше по сети; доступ к частной сети имеет другую топологию.

Почему handshake не подтверждает интернет?

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

Как проверить DNS?

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

Охватывает ли пример IPv6?

Нет. Это IPv4-пример для управляемого клиента без пригодного альтернативного IPv6-пути. Действующий IPv6 default route требует отдельно спроектированной конфигурации и собственных проверок поведения.

Как отозвать одно устройство?

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

Что проверить после перезагрузки?

Проверьте службу, действующих пиров, forwarding, точные правила, область DNS и новый запрос. Работающая служба сама по себе не доказывает работоспособность интернет-шлюза для задачи.

Когда выбрать обслуживаемый сервис?

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

Область применения: Подготовлено по официальным материалам Ubuntu 24.04 LTS; полный сквозной тест автором не выполнялся. Пример IPv4 не подтверждает IPv6 или kill switch. Используйте собственные или разрешенные узлы и соблюдайте применимые законы и правила сервиса.

Источники:

WireGuard, "Quick Start": https://www.wireguard.com/quickstart/
WireGuard, "Installation": https://www.wireguard.com/install/
Ubuntu Noble, "wg-quick(8)": https://manpages.ubuntu.com/manpages/noble/man8/wg-quick.8.html
Ubuntu Server, "Using the VPN as the default gateway": https://ubuntu.com/server/docs/how-to/wireguard-vpn/vpn-as-the-default-gateway/
Ubuntu Noble, "resolvectl(1)": https://manpages.ubuntu.com/manpages/noble/man1/resolvectl.1.html
Ubuntu Noble, "ip-address(8)": https://manpages.ubuntu.com/manpages/noble/man8/ip-address.8.html

Sources checked 9 октября 2026 года.

Похожие статьи:

Настройка сервера WireGuard: шлюз Ubuntu и проверка