VPN подключается, но устройства LAN недоступны: что проверить

Трафик входит в туннель, шлюз отвечает на собственный адрес, а за ним ничего не отвечает. Эта картина обычна и не является противоречием: ответ от шлюза доказывает, что туннель завершился, и ничего не доказывает о том, что происходит с пакетом, адресованным за него. Оба теста задействуют разные пути кода на одной и той же машине.

С этого момента проверяйте что-нибудь по ту сторону шлюза. Собственный адрес шлюза будет отвечать дальше, как бы ни было сломано перенаправление.

Шлюз отвечает из собственного стека

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

Страницы администрирования, достигаемые через туннель, тоже относятся к первой категории. Они свидетельствуют о туннеле, а не о сети за ним.

Проследите поток до первой границы, которая его отбрасывает

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

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

Обратные маршруты и межсетевые экраны хоста отказывают по отдельности

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

Проверьте обратный путь намеренно: отправьте с клиента и наблюдайте за возвратом. Односторонняя запись решает за секунды то, чего не решит час догадок.

Подтверждайте каждый шаг адресом источника клиента

Выполняйте проверки по порядку и сохраняйте каждый вывод, потому что ценность в сравнении, а не в отдельной строке. Команды ниже фиксируют адрес источника, показывают выбранный маршрут и записывают обе стороны перенаправления. Замените свой хост LAN и интерфейс туннеля.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Запрос маршрута показывает, отправил бы клиент этот пакет в туннель вообще, а ping показывает, вернулось ли что-нибудь от хоста. Сравнение двух записей отделяет прибытие от ухода, поскольку кадр на интерфейсе туннеля без пары на интерфейсе LAN — это решение о перенаправлении, а не сбой службы. Когда обе записи показывают запрос, а только одна показывает ответ, оставшийся подозреваемый — обратный маршрут.

Запишите, какой адрес ответил и какой перенаправленный пункт назначения отказал. Эта фраза делает отчёт пригодным к действию вместо утверждения, что сервер недоступен.