Рукопожатие 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 прежде чем менять любые настройки шифрования.

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