VPN-клиент: CLI или GUI на Linux — что удобнее

MAATRIX

На Linux один и тот же VPN можно поднять двумя разными путями: набрать пару команд в терминале или кликнуть «Подключить» в апплете NetworkManager. Разработчики и системные администраторы обычно тянутся к CLI по привычке, но это не всегда лучший выбор — на десктопе с несколькими профилями и Wi-Fi-сетями GUI реально экономит время. Разберём, чем отличаются оба подхода на практике и какой выбрать в зависимости от задачи: голый сервер, рабочий ноутбук или CI-пайплайн.

Два способа подключения VPN на Linux

По сути это два интерфейса к одному и тому же ядерному функционалу. WireGuard живёт как интерфейс wg0 в ядре, OpenVPN создаёт tun/tap-устройство — и неважно, кто именно скомандовал ядру их поднять: скрипт wg-quick, бинарник openvpn или служба NetworkManager через свой плагин.

Разница не в «настоящем» и «ненастоящем» VPN, а в том, кто управляет жизненным циклом соединения:

• CLI (wg-quick, openvpn, systemd-юниты) — вы сами вызываете команду или полагаетесь на systemd. Никакого демона-посредника, минимум абстракций.
• GUI/NetworkManager — соединением управляет демон NetworkManager, а wg-quick/openvpn — интерфейс к нему: графический (nm-applet, nm-connection-editor) или консольный (nmcli). NetworkManager сам следит за маршрутами, DNS и переключением сетей.

Здесь же стоит уточнить: nmcli — это тоже командная строка, но не то же самое, что «чистый» CLI. Она не заменяет wg-quick, а управляет тем же NetworkManager, что и графический интерфейс. Это важно для сравнения ниже — на практике выбор часто идёт не между «CLI и GUI», а между «сырым CLI без посредников» и «NetworkManager (в любом виде — графическом или консольном)».

CLI напрямую: wg-quick и openvpn без посредников

Самый прямой путь — команды из коробки пакетов wireguard-tools и openvpn, без демона-менеджера сети. Для WireGuard:

sudo apt install wireguard-tools
sudo wg-quick up /etc/wireguard/wg0.conf
sudo wg-quick down wg0

wg-quick сам читает секцию [Interface] с ключами и адресом, поднимает интерфейс, прописывает маршруты из AllowedIPs и накатывает PostUp/PostDown-хуки, если они заданы в конфиге. Как собрать сам конфиг и ключи с нуля, подробно разобрано в статье про установку WireGuard на VPS.

Для OpenVPN аналогично — без демона, просто запуск бинарника с файлом клиентского профиля:

sudo openvpn --config client.ovpn
# или в фоне с логом:
sudo openvpn --config client.ovpn --daemon --log /var/log/openvpn-client.log

Автозапуск при старте системы — через systemd-юниты, которые ставятся вместе с пакетами:

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now openvpn-client@client

Здесь client — это имя файла client.conf в /etc/openvpn/client/ без расширения. Что удобно: systemctl status wg-quick@wg0 и journalctl -u wg-quick@wg0 дают ровно ту диагностику, которую вы привыкли получать от любого другого systemd-сервиса — без отдельного GUI-лога, который ещё нужно найти.

GUI: NetworkManager, апплет и nm-connection-editor

На десктопных дистрибутивах (Ubuntu Desktop, Fedora Workstation, Mint) NetworkManager обычно уже управляет всеми сетевыми интерфейсами, и добавление VPN — это добавление ещё одного профиля рядом с Wi-Fi-сетями. Понадобятся плагины:

sudo apt install network-manager-openvpn-gnome network-manager-wireguard

Дальше — через nm-connection-editor или прямо из системного трея: «Настройки сети» → «VPN» → «+» → импорт .ovpn-файла или ручной ввод WireGuard-ключей. Профиль сохраняется в /etc/NetworkManager/system-connections/, подключение и отключение — переключателем в апплете, без единой команды в терминале.

Что даёт этот слой поверх голого wg-quick/openvpn:

• Несколько сохранённых профилей переключаются кликом — не нужно помнить пути к конфигам.
• Автоматическое управление DNS и маршрутами при смене сети (Wi-Fi дома → LAN в офисе) — NetworkManager сам решает, когда переподнять туннель.
• Уведомления о разрыве соединения прямо в системном трее.
• Единый интерфейс для VPN, Wi-Fi и Ethernet — не нужно переключаться между разными инструментами.

Минус — на голом сервере без графического окружения весь этот слой просто не нужен, а иногда и не установлен по умолчанию.

nmcli: командная строка к тому же NetworkManager

Если нужен CLI, но хочется удобства NetworkManager (например, автопереключение и хранение нескольких профилей), nmcli — средний вариант. Импорт готового конфига:

nmcli connection import type wireguard file /etc/wireguard/wg0.conf
nmcli connection import type openvpn file client.ovpn

Управление без единого клика мышью:

nmcli connection up wg0
nmcli connection down wg0
nmcli connection show --active

Разница с wg-quick/openvpn не в командах, а в том, кто хранит состояние. wg-quick up — это разовое действие процесса, который завершается сразу после настройки интерфейса (сам туннель дальше работает в ядре без него). nmcli connection up — команда демону NetworkManager, который потом сам отвечает за реконнект, DNS и маршруты в фоне. Для скриптов и автоматизации nmcli даёт машиночитаемый вывод:

nmcli -t -f NAME,TYPE,DEVICE connection show --active

Сравнение по критериям

Про построение kill switch на уровне iptables/nftables для обоих вариантов — отдельная статья про kill switch для VPN.

Когда выбрать CLI без посредников

Прямой wg-quick/openvpn — правильный выбор в нескольких сценариях:

• Сервер без графической оболочки. На VPS вообще нет смысла тянуть NetworkManager ради одного статического туннеля — лишний демон, лишняя точка отказа, лишний повод для конфликтов с сетевой настройкой, если на сервере уже используется netplan или systemd-networkd напрямую.
• CI/CD и автоматизация. В пайплайне поднять VPN одной командой wg-quick up в начале джобы и wg-quick down в конце — предсказуемо и без зависимости от D-Bus-сессии, которая нужна NetworkManager.
• Site-to-site и постоянные туннели. Когда соединение должно жить всегда и не «мигрировать» между сетями (сервер физически не двигается), автопереключение NetworkManager — не преимущество, а лишняя переменная.
• Минимальный набор зависимостей. На встраиваемых системах и в контейнерах NetworkManager часто просто недоступен или избыточен.

Когда выбрать GUI или nmcli

NetworkManager (в графическом виде или через nmcli) выигрывает там, где VPN — не единственное сетевое подключение, а одно из многих, между которыми регулярно переключаются:

• Рабочий ноутбук с несколькими VPN-профилями — например, отдельные туннели для разных серверов или клиентов. Клик в трее быстрее, чем помнить пути к конфигам.
• Частая смена сетей. Дом → офис → кафе с открытым Wi-Fi — NetworkManager сам поднимает и опускает туннель, синхронизирует DNS, не оставляя окна с трафиком в обход VPN дольше, чем нужно.
• Пользователи, не работающие в терминале каждый день. Если за машиной сидит не только инженер, разумнее оставить переключатель в системных настройках, чем учить набирать команды.
• Нужны визуальные уведомления о состоянии соединения — GUI даёт это из коробки, CLI требует отдельного скрипта-обёртки с notify-send.

На практике многие держат оба варианта параллельно: серверные туннели — через systemd-юниты и wg-quick, а рабочий ноутбук — через NetworkManager, потому что это разные задачи с разными требованиями к надёжности и удобству.

Гибридный вариант: NetworkManager из скрипта

Если хочется автоматизации, но не хочется терять удобство хранения профилей в NetworkManager, nmcli закрывает оба требования одновременно. Пример скрипта переключения между двумя профилями по расписанию через cron:

#!/bin/bash
# /usr/local/bin/vpn-switch.sh
CURRENT=$(nmcli -t -f NAME connection show --active | grep -E "^wg-|^ovpn-")
if [ "$CURRENT" = "wg-office" ]; then
    nmcli connection down wg-office
    nmcli connection up wg-home
else
    nmcli connection down wg-home
    nmcli connection up wg-office
fi

Это тот случай, когда деление на «CLI vs GUI» условно: под капотом работает GUI-стек (NetworkManager со всеми его плюсами — DNS, маршруты, реконнект), а взаимодействие с ним полностью скриптуемое. Минус один — на сервере без NetworkManager этот путь просто недоступен, там остаётся только прямой wg-quick/openvpn.

Что касается протокола (WireGuard против OpenVPN) — это отдельный выбор, не зависящий от CLI или GUI: оба поддерживаются обоими путями примерно одинаково полно. Если этот вопрос ещё не закрыт, есть отдельный разбор какой протокол VPN выбрать под конкретные сценарии.

Частые вопросы