Happ на Linux: установка и настройка WireGuard
Что именно ставить на Linux
Отдельного «приложения Happ» под Linux в привычном смысле нет — и это нормально. Happ выдаёт вам конфигурацию WireGuard, а сам протокол в современном ядре Linux встроен начиная с версии 5.6. То есть всё, что нужно для туннеля, либо уже есть в системе, либо ставится одним пакетом утилит. Это делает Linux одной из самых прозрачных платформ для работы с Happ.
На Ubuntu и Debian базовый набор ставится командой apt install wireguard wireguard-tools resolvconf. Пакет wireguard подтянет модуль ядра при необходимости, wireguard-tools даёт команды wg и wg-quick, а resolvconf корректно применяет DNS из конфигурации. На Fedora аналог — dnf install wireguard-tools, на Arch — pacman -S wireguard-tools.
Если вы предпочитаете графику, на GNOME и KDE есть интеграция WireGuard прямо в сетевой менеджер: NetworkManager умеет импортировать .conf через nmcli connection import type wireguard file happ.conf. Но для серверов и для понимания происходящего удобнее командная строка — она же проще автоматизируется и не зависит от окружения рабочего стола.
Проверьте версию ядра командой uname -r перед началом. Если у вас ядро 5.6 и новее, модуль wireguard уже в составе и ничего собирать не нужно. На старых LTS-ядрах пакет установит DKMS-модуль автоматически. Эта мелкая проверка избавляет от загадочных ошибок «Unable to access interface: Protocol not supported» позже.
Импорт конфигурации Happ
Получив профиль в Happ, экспортируйте его как файл WireGuard (.conf) или скопируйте текст конфигурации. Внутри будут две секции: [Interface] с вашим приватным ключом, адресом и DNS, и [Peer] с публичным ключом сервера, endpoint и AllowedIPs. Сохраните этот файл, например, как /etc/wireguard/happ.conf и обязательно ограничьте права: chmod 600 /etc/wireguard/happ.conf.
Права на файл — не формальность. В [Interface] лежит приватный ключ, и если конфиг доступен на чтение всем пользователям, любой локальный процесс сможет его прочитать и использовать ваш туннель. Команда chmod 600 оставляет доступ только владельцу. Для многопользовательских машин это обязательный шаг, а не рекомендация на будущее.
Поднять туннель вручную можно командой wg-quick up happ (если файл лежит в /etc/wireguard и называется happ.conf). Опустить — wg-quick down happ. Эти две команды покрывают 90% повседневной работы: включил перед сессией, выключил после. wg-quick сам создаёт интерфейс, настраивает маршруты и применяет DNS из конфига.
Если в конфигурации Happ указан DNS, а у вас не установлен resolvconf или systemd-resolved, wg-quick может ругаться на невозможность применить DNS. Решения два: поставить resolvconf, либо убрать строку DNS из конфига и задать резолверы системно. Первый вариант предпочтительнее — иначе DNS-запросы пойдут мимо туннеля, и провайдер увидит, какие домены вы открываете.
- Проверить версию ядра через uname -r
- Установить wireguard-tools для вашего дистрибутива
- Сохранить конфиг Happ в /etc/wireguard/happ.conf
- Выставить права chmod 600 на файл конфигурации
- Поднять туннель командой wg-quick up happ
Автозапуск через systemd
Чтобы туннель поднимался при загрузке, используйте шаблонный сервис systemd: systemctl enable wg-quick@happ и systemctl start wg-quick@happ. Имя после @ должно совпадать с именем конфигурационного файла без расширения. Теперь после перезагрузки Linux сам поднимет happ.conf, и вам не придётся вспоминать команду каждый раз.
Состояние сервиса проверяется командой systemctl status wg-quick@happ. В выводе видно, активен ли туннель и не было ли ошибок при старте. Если сервис падает с ошибкой про резолвинг DNS на ранней загрузке, добавьте зависимость от network-online.target — иногда WireGuard стартует раньше, чем поднимется сетевой стек.
Для ноутбуков, которые часто меняют сети, автозапуск через systemd иногда мешает: туннель поднимается до того, как Wi-Fi подключился, и виснет. В таком сценарии разумнее не включать автозапуск, а поднимать туннель вручную либо повесить его на смену сети через NetworkManager-dispatcher. Здесь всё зависит от вашего профиля использования.
Удобный приём для диагностики — команда wg без аргументов (от root). Она показывает все активные интерфейсы WireGuard, последний handshake с пиром и счётчики переданных байт. Если latest handshake обновляется и байты растут — туннель живой. Если handshake висит на «никогда» — пакеты до сервера не доходят, и проблема в endpoint, портах или сети.
Проверка туннеля и DNS
После up первым делом сравните внешний IP до и после: curl ifconfig.me покажет видимый адрес. Если он сменился на адрес сервера из конфига — маршрутизация работает. Если адрес прежний, скорее всего AllowedIPs в [Peer] не включает 0.0.0.0/0, и через туннель идёт не весь трафик, а только подсеть сервера.
DNS на Linux проверяется отдельно и часто оказывается слабым местом. Команда resolvectl status (на системах с systemd-resolved) покажет, какие серверы используются для интерфейса. Они должны совпадать с DNS из конфигурации Happ. Если там по-прежнему стоит резолвер провайдера, запросы утекают, и стоит разобраться с resolvconf/resolved.
Утечки удобно ловить через mtr и dig. dig @1.1.1.1 example.com покажет, доходит ли резолвинг до нужного сервера, а mtr ifconfig-адрес-сервера выявит потери пакетов на пути. На UDP-протоколе вроде WireGuard потери на промежуточных хопах бьют по стабильности сильнее, чем на TCP, поэтому диагностика маршрута здесь особенно полезна.
Финальный штрих — записать рабочую последовательность команд себе в заметки или короткий скрипт. На Linux настройка редко ломается сама по себе, но при переустановке системы или переходе на новую машину вы развернёте Happ за пару минут, если под рукой готовый конфиг и список шагов, а не смутные воспоминания о том, что «там что-то с wg-quick».
Типичные ошибки и их причины
«RTNETLINK answers: Operation not permitted» почти всегда означает, что вы запускаете wg-quick без прав root. WireGuard создаёт сетевой интерфейс и правит таблицу маршрутизации, а это требует привилегий. Запускайте через sudo или из-под root, либо настройте сервис systemd, который работает с нужными правами по умолчанию.
«Unable to access interface: Protocol not supported» указывает на отсутствие модуля ядра. Это бывает на нестандартных или очень старых ядрах. Проверьте modprobe wireguard: если модуль не грузится, нужно поставить пакет с DKMS-модулем или обновить ядро. На минимальных контейнерах и некоторых VPS модуль приходится включать отдельно.
Если туннель поднимается, handshake проходит, но интернета нет — почти всегда виноваты DNS или маршрутизация. Проверьте, что 0.0.0.0/0 в AllowedIPs, и что DNS из конфига реально применился. Отдельная ловушка — конфликт с уже работающим VPN или корпоративным маршрутом: два клиента, претендующих на маршрут по умолчанию, неизбежно мешают друг другу.
Наконец, если ничего из перечисленного не помогает, соберите данные перед обращением в поддержку: вывод wg, uname -r, дистрибутив и версию, текст ошибки wg-quick. На Linux диагностика по таким данным занимает минуты, потому что всё прозрачно и воспроизводимо — в отличие от закрытых клиентов, где приходится гадать о внутреннем состоянии приложения.