Підключилися до OpenVPN, але нічого не завантажується: шлях від клієнта назовні

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

Почніть з клієнта і йдіть назовні

Виконайте три перевірки в цьому порядку і запишіть, де падає перша. Пінгуйте адресу тунелю на сервері — це доводить, що сам тунель несе трафік. Пінгуйте публічну адресу за номером — це доводить пересилання й трансляцію без участі розв'язання імен. Потім спробуйте розв'язати ім'я хоста — це єдина перевірка, яка задіює DNS. Кожен результат знімає цілий шар підозр.

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

Два перехоплення показують, де зупиняються пакети

Поки з клієнта йде ping на публічну адресу, зробіть одне перехоплення на інтерфейсі тунелю і одне на вищому каналі, який має виходити в інтернет. Запустіть обидва одночасно, щоб мітки часу збіглися.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

Поле dev у цьому виводі — те ім'я, яке знадобиться правилу NAT пізніше, тож збережіть його.

Пересилання — це перемикач у ядрі й політика міжмережевого екрана

Ядро має взагалі погодитися пересилати. Прочитайте поточне значення, а потім зробіть налаштування постійним, замість того щоб писати його лише в працююче ядро:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Пересилання — це лише половина. На хості з UFW політика пересилання задається в /etc/default/ufw і має бути ACCEPT, перш ніж перезавантаження налаштувань набуде сили. Відкидання за замовчуванням на шляху пересилання залишає рукостискання цілком здоровим, але тихо викидає кожен пакет, який намагається вийти через тунель, і це саме той симптом, з якого ви почали.

Хости, які керують nftables напряму, мають те саме питання в іншому синтаксисі. Дивіться на лічильники ланцюга пересилання, поки триває перевірка з клієнта, бо ланцюг, до якого звертаються, і ланцюг, який відкидає, у файлі конфігурації виглядають однаково.

Назвіть справжній інтерфейс виходу в правилі NAT

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Класична помилка — правило, скопійоване з посібника, де сказано -o eth0 на машині, чий адаптер називається інакше. Правило встановлюється без попередження, ні з чим не збігається, і клієнт досі без інтернету. Пул — друга половина тієї самої помилки: якщо сервер видає 10.44.0.0/24, а правило покриває 10.8.0.0/24, ніщо ніколи не збіжиться.

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

iptables -t nat -L POSTROUTING -v -n

Нульовий лічильник пакетів після справжньої перевірки з клієнта означає, що збіг неправильний, а не що тунель зламано. Щойно він почне збігатися, збережіть набір правил, щоб він пережив перезавантаження; виправлення, яке живе лише в історії вашої оболонки, зникає при першому перезавантаженні.

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

DNS — друга поломка за першою

Робочий ping за адресою при падінні імен — це проблема розв'язувача, і вона має свою причину. Клієнт, який зберігає свій локальний розв'язувач, надсилає ці запити в повний тунель і чекає на відповідь, яка ніколи не приходить, бо локальний розв'язувач тепер на неправильному боці маршруту.

Віддайте розв'язувач із сервера, щоб клієнт знав, куди питати. Два записи дають клієнту запасний варіант, якщо перший недоступний, і обидва мають бути розв'язувачами, які тунель справді дозволяє.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Клієнти Windows після цього все одно можуть повернутися до локального розв'язувача, і саме це покликаний відвертати block-outside-dns, ціною втрати імен, які може розв'язати лише локальна мережа. Клієнти Linux із systemd-resolved часто ігнорують виданий розв'язувач, якщо скрипт його не встановить, тому перевірте resolvectl status для пристрою тунелю, перш ніж зробити висновок, що видачу проігноровано.

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