Туннель VPN не подключается: где на самом деле останавливаются пакеты
Туннель, который так и не формируется, оставляет пустой журнал с обеих сторон. Проверьте, не отбрасываются ли GRE, ESP или UDP 4500, и определите NAT оператора, прежде чем править сервер.
Клиент продолжает повторять попытки, журнал обрывается до завершения рукопожатия, а сервер не фиксирует вообще ничего. Эта картина уводит от учётных данных к пути: что-то между двумя концами отказывается пропускать протокол, нужный туннелю. Определите, где останавливаются пакеты, прежде чем трогать любую из двух конфигураций, потому что отфильтрованный протокол и неверный пароль дают в большинстве клиентов одну и ту же дружелюбную ошибку. Тесты упорядочены по затратам, самый дешёвый первым.
Докажите, где останавливается трафик
Снимайте одновременно на исходящем интерфейсе клиента и на сервере. Сравните, что ушло, с тем, что пришло, и отметьте, в каком направлении появляется разница.
Ничего на сервере означает, что путь или первый NAT отбрасывает трафик, а приходы без ответов указывают на межсетевой экран на сервере или на несуществующий обратный маршрут. Маршрутизатор, который часто завершает туннели, обычно не ведёт полезного журнала, поэтому снимок становится записью. Запишите порт назначения и номер протокола, поскольку обе неисправности выглядят в окне клиента одинаково.
PPTP умирает без протокола 47
PPTP передаёт управление по TCP 1723, а данные внутри GRE, который является IP-протоколом 47, а не номером порта. Переадресация только 1723 даёт классический результат: соединение проходит аутентификацию и затем замолкает, потому что правила для протокола, несущего полезную нагрузку, нет. Клиент не может отличить это от отклонённого пароля, поэтому снимок должен быть сделан до изменений конфигурации.
Проброс работает в противоположную сторону от входящей переадресации, и прошивка достаточно часто использует одну метку для обоих, чтобы запутать всех. На клиенте Linux локальный межсетевой экран может отбросить GRE задолго до того, как маршрутизатор вообще будет задействован, поэтому протоколу 47 нужно собственное правило, а помощник conntrack должен быть загружен. ufw в Ubuntu хранит эти правила в файле before, потому что обычные правила allow не могут выразить номер протокола. Затем перезагрузите межсетевой экран вместо перезапуска машины.
# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep greL2TP и IPsec за двумя NAT
L2TP внутри IPsec требует UDP 500 для обмена ключами, UDP 4500 при обнаружении NAT и ESP как протокол 50. Каждый из них фильтруется независимо, поэтому правило, разрешающее один, ничего не доказывает о двух других. Два маршрутизатора последовательно переводят каждый пакет дважды, и концы больше не сходятся в том, что было согласовано.
Переведите внешний модем в режим моста или отключите NAT на внутреннем маршрутизаторе, чтобы публичный адрес доходил до устройства, завершающего туннель. Там, где невозможно ни то, ни другое, туннель нужно инициировать изнутри границы двойного NAT, а не завершать там.
Сети операторов и совместное использование адресов
WAN-адрес внутри 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 или 100.64.0.0/10 означает, что у маршрутизатора нет публичного адреса и никакая входящая переадресация из интернета до него не дойдёт. NAT операторского уровня дополнительно фильтрует протоколы, которых не ожидает, а GRE часто страдает на мобильных каналах. Сравнивайте WAN-адрес на самом маршрутизаторе, а не тот, который сайт проверки сообщает для клиента за ним.
Запуск того же маршрутизатора на проводной линии одним тестом отделяет вывод об операторе от ошибки конфигурации. Там, где оператор отказывает протоколу, остаются варианты другого транспорта на 443 или туннеля, инициированного изнутри.
Прочитайте список слушателей, прежде чем закрывать порты
Тревожное сканирование портов часто оказывается всего лишь набором функций, поставляемым включённым. Проведите инвентаризацию слушателей, сопоставьте каждый сокет с функцией, а затем отключите функцию вместо блокировки порта, чтобы два представления не расходились.
ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500Значения SoftEther по умолчанию — хороший пример: TCP 443, 992 и 5555, причём функции L2TP/IPsec и DNS-туннеля добавляют собственные сокеты. Отключение этих функций убирает слушателей, а не скрывает их, и проверка с внешнего хоста говорит, пропускает ли оператор порт вообще. Слушатель, отвечающий локально, всё равно может быть закрыт выше по потоку, поэтому сравнивайте собственный WAN-адрес маршрутизатора с тем, что сообщает внешний сервис.