Що має дозволяти 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

Тримайте поруч із перевіркою операційні основи: місце для оновлень, обмежені журнали, адміністративний доступ, що не залежить від тунелю, консоль відновлення й нотатку про те, що відбувається з профілями клієнтів, коли інстанс перебудовується і його публічна адреса змінюється. Якщо потрібний інтерфейс або модель пересилання просто недоступні, жодна зміна на боці клієнта їх не забезпечить, і чесний наступний крок — інший тип інстансу, а не більше конфігурації.