Этот адрес L2TP — это IPCP, а не аренда DHCP в локальной сети

Внутренний адрес приходит из переговоров PPP, а не от DHCP-сервера офиса. Посмотрите, какой этап его назначает, почему локальная сеть не может ответить и что проверять.

Соединение поднимается, и адаптер показывает адрес из диапазона офиса, поэтому естественный вывод — VPN дал вам адрес локальной сети и тем самым поместил вас в неё. Ни одна из двух половин не совсем верна. L2TP несёт сеанс PPP, а PPP согласует внутренний адрес IPv4 с помощью IPCP. Этот адрес — параметр сеанса, согласованный двумя сторонами, а не аренда, выданная DHCP-сервером офиса, и обладание им не делает вас соседом на офисном кабеле.

Два адреса в одном соединении

В соединении L2TP есть два независимых согласования. Внешнее строит защищённый путь между вашим устройством и конечной точкой VPN поверх любой уже имеющейся сети. Внутреннее — это сеанс PPP, и именно там согласуются адрес вашего сеанса и адрес другой стороны. Интернет-трафик может выходить совсем под третьим адресом — публичным адресом конечной точки, поэтому страница проверки VPN и адрес адаптера редко совпадают.

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

Что именно делает IPCP

IPCP — это протокол управления IPv4 для PPP. Каждая сторона отправляет сообщения Configure-Request с описанием нужных опций, и опция адреса — одна из них. Клиент, у которого ещё нет адреса, обычно запрашивает с 0.0.0.0, а сервер отвечает сообщением Configure-Nak, несущим адрес, который он хочет дать клиенту. Затем клиент запрашивает этот адрес, и сеанс поднимается с локальным и удалённым адресом.

Этот обмен описан в спецификациях PPP и IPCP, и он объясняет деталь, похожую на ошибку: адрес выбирает сервер по собственной политике, которая может быть пулом, настройкой для отдельного пользователя или адресом, привязанным к аутентифицированной личности. Когда пул исчерпан или политика противоречит запросу, аутентификация может пройти, а согласование адреса — нет, и клиент сообщает о соединении, которое так и не стабилизируется.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Строка журнала pppd с локальным и удалённым адресом — это успешный конец того согласования. Её отсутствие рядом с успешной аутентификацией указывает на этап адреса, а не на учётные данные.

Почему локальная сеть не может вам ответить

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

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

Сначала проверьте сеанс, затем маршрут

Сначала проверьте интерфейс, затем маршруты, затем одно важное назначение. У каждого шага свой режим отказа, а проверка всех трёх сразу даёт вывод, который вы потом не сможете защитить.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

Держите три этапа раздельно

Аутентификация, согласование адреса и пересылка отказывают по-разному, и у каждого свой владелец. Учётные данные — проблема идентичности, исчерпание IPCP — проблема политики сервера, а отсутствующий обратный маршрут — проблема проектирования сети. Сообщать обо всех трёх как «VPN сломана» гарантирует медленное исправление.

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

Похожие статьи