Что должен разрешать VPS, прежде чем разместить ваш VPN

Инстанс загружается, установка пакетов проходит успешно, и служба даже сообщает о рабочем состоянии, но ничего не подключается. Такая картина типична для виртуальных частных серверов, потому что гость, который свободно выходит в интернет, всё ещё может не суметь создать интерфейс, которого требует ваш протокол. Пять проверок отделяют хост, способный обслуживать туннель, от того, который только выглядит готовым, и первая неудачная проверка обычно объясняет всё последующее. Каждая дешева в запуске и заканчивается решением, а не заметкой.

Подтвердите интерфейс, который нужен протоколу

OpenVPN поверх TUN нужен символьное устройство и модуль ядра за ним; WireGuard нужна собственная поддержка в ядре или реализация в пространстве пользователя с соответствующими ожиданиями. Управляемые контейнеры могут делить ядро хоста, которое никогда не открывает устройство, а некоторые платформы вообще запрещают создание туннельных интерфейсов независимо от того, что установлено.

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Отказ на первой паре означает, что TUN недоступен и режим по умолчанию OpenVPN не может запуститься; отказ в последней строке означает, что интерфейса WireGuard в ядре нет. Документация ядра о TUN/TAP описывает устройство, которое проверяет первая проверка. Ни один из этих сбоев не исправляется переустановкой пакета VPN.

Помните, что у входящего пути два владельца

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

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

Планируйте обратный путь, а не только выход

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Решите вопрос IPv6 явно

IPv6 приходит через несколько механизмов, которые ведут себя по-разному для шлюза: адрес на инстансе, маршрутизируемый префикс или ничего. Только маршрутизируемый префикс позволяет серверу обычным образом выдавать адреса клиентам. Предположение, что работающий адрес IPv6 на хосте означает пригодный клиентский префикс, — это ошибка, которая позже проявляется как наполовину сломанное соединение. Это тот вид неисправности, который переживает любую проверку, выполненную только с IPv4.

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

Докажите это с внешнего клиента

Локальный статус службы описывает один процесс на одном хосте. Полезная проверка — авторизованный клиент в другой сети, который подключается с профилем, который вы собираетесь распространять, затем достигает приложения и разрешает имя. Подключитесь ещё раз, потому что туннель, работающий только с первой попытки, не выполняет требование, которое важнее всего на практике.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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