Рукостискання PiVPN працює, сторінки зависають: перевірте MASQUERADE

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

Почніть із того, до чого клієнт може й не може дістатися

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

Адреса тунелю, яка відповідає на ping, поки публічні сайти вичерпують час, — це ознака проблеми з пересиланням або трансляцією, а не зламаного рукостискання. Власна панель стану клієнта не може їх розрізнити, бо вона знає лише те, що канал керування піднято. Перевірте на сервері інтерфейс тунелю за допомогою ip -br addr show tun0 і переконайтеся, що призначена клієнтові адреса потрапляє в пул, який ви налаштували. Якщо пул і адреса клієнта не збігаються, виправте це першим, бо кожне правило нижче зіставляється з пулом.

Далі запитайте сервер, який інтерфейс він використав би для досягнення публічної адреси. ip route get 203.0.113.9 друкує вибраний пристрій і джерело в першому рядку. Запишіть назву цього пристрою, бо саме це значення має бути в правилі NAT.

Прочитайте правило, яке вирішує, чи виходять пакети

MASQUERADE переписує пакет лише тоді, коли пакет виходить через інтерфейс, названий у правилі. Правило, прив’язане до дротового пристрою, нічого не робить для трафіку, що виходить через Wi-Fi, і пакет зберігає свою приватну адресу джерела аж до вищого маршрутизатора. У того маршрутизатора немає зворотного маршруту до вашого пулу тунелю, тож він відкидає відповідь, і клієнт бачить з’єднання, яке відкривається і потім помирає. Симптом зростає з тим, скільки сторінки встигає прийти до того, як потрібна перша відповідь.

Перелічіть живу таблицю і читайте стовпець вихідного інтерфейсу, а не просто шукайте слово MASQUERADE. Вивід у формі додавання порівнювати легше, ніж відформатований список:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

На Raspberry Pi, який колись використовував Ethernet, а тепер Wi-Fi, застаріла назва майже завжди і є всією історією. Інсталятор записав, який пристрій був присутній під час налаштування, і збережений набір правил відтворює його під час кожного завантаження. Порівняйте пристрій із пошуку маршруту з тим, що в правилі, перш ніж змінювати щось інше. Якщо вони збігаються, інтерфейс не ваша проблема, і вам варто перейти до лічильників в останньому розділі. Якщо різняться, виправлення — це зміна одного слова у файлі збереження.

Виправте збережений набір правил, а не лише той, що працює

Правка лише живої таблиці тримається до наступного перезавантаження, а цього рівно достатньо, щоб переконати вас, що проблему вирішено. Правила, які повертаються під час завантаження, живуть у файлі, який перезавантажує пакунок збереження міжмережевого екрана. На образах Pi на базі Debian цей файл зазвичай /etc/iptables/rules.v4.

Зробіть копію, перш ніж його чіпати, потім замініть вихідний інтерфейс у рядку MASQUERADE на записаний пристрій, наприклад -o wlan0 замість -o eth0. Залиште діапазон джерела як є, якщо ваш пул клієнтів не змінився. Перезавантажте і переконайтеся, що правило тепер називає правильний пристрій:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Два сусідні налаштування легко забути. sysctl net.ipv4.ip_forward має повідомляти 1, а вищий маршрутизатор не повинен сам фільтрувати приватні адреси джерел.

Доведіть, що правило спрацьовує, потім ізолюйте те, що ще повільно

Лічильники — єдиний чесний доказ того, що правило збіглося. Запустіть докладний список, почніть завантаження на клієнті і запустіть його знову. Стовпці пакетів і байтів поруч із вашим правилом мають зростати, а правило, яке залишається на нулі, все ще не збігається. Якщо лічильники рухаються, але сторінки все ще падають, порівняйте діапазон джерела з фактичним пулом за допомогою grep -n "^server " /etc/openvpn/server.conf. Якщо вони рухаються і сторінки завантажуються, але пропускна здатність погана, трансляція завершена, а решта проблеми в іншому місці.

Порівняйте дві передачі від одного клієнта, одну до хоста в локальній мережі і одну через тунель до того самого хоста. Повільно в обох випадках указує на зовнішній канал Pi або з’єднання Wi-Fi, а не на VPN. Повільно лише через тунель указує на MTU і повторні передачі, які можна оглянути за допомогою ip -s link show tun0 перш ніж змінювати будь-які налаштування шифрування.

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