Адрес VPN против аренды DHCP в локальной сети: кто выдаёт IP-адрес туннеля?

Клиент VPN показывает адрес, которого никогда нет в файле аренды локальной сети. Прочитайте клиент, полезную нагрузку IKEv2 и пул шлюза, чтобы найти настоящего выдающего.

Подключите клиент и смотрите на адаптер, а не на значок Wi-Fi. Адрес вроде 10.80.0.14 может находиться на туннеле, хотя ни один DHCP-сервер в офисной сети ни разу не записал эту аренду. Именно процесс, выбравший номер, определяет, откуда начинать поиск неисправности.

На клиенте всё выглядит одинаково: один адрес IPv4, одна маска, иногда шлюз по умолчанию. Разница проявляется только тогда, когда вы спросите, кто отвечает за этот адрес и кто ведёт его учёт.

Прочитайте адрес туннеля на стороне клиента

Windows покажет разницу, если читать весь блок, а не первую строку. ipconfig /all печатает описание адаптера, физический адрес и строку DHCP. Адаптер дозвона PPP или IKEv2 обычно сообщает, что DHCP отключён, потому что соединение согласовало адрес при дозвоне, а не взяло его в аренду у сервера локальной сети. Туннельный адаптер с включённым DHCP необычен и заслуживает отдельного разбора.

Linux распределяет ту же информацию между двумя инструментами. ip -4 addr show dev tun0 даёт адрес и длину префикса. nmcli -f IP4 connection show work показывает, пришло ли значение из профиля соединения, из обмена DHCP на канале или из протолкнутой конфигурации. WireGuard — самый ясный случай: wg-quick применяет строку Address из файла конфигурации при появлении интерфейса, и ни один партнёр ничего не выделяет в момент подключения.

Префикс тоже кое о чём говорит. /32 или маска 255.255.255.255 означает, что шлюз рассчитывает маршрутизировать к одному адресу узла, а более широкая маска указывает на подсеть на канале где-то за туннелем.

Что несёт полезная нагрузка конфигурации IKEv2

У IKEv2 для этой задачи есть отдельный механизм. Полезная нагрузка конфигурации, описанная в RFC 7296, раздел 3.15.1, несёт атрибуты вроде INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS и их аналоги IPv6. Клиент отправляет атрибут нулевой длины, когда у него нет предпочтения, а отвечающая сторона возвращает значение, которое хочет использовать. Этот обмен идёт внутри IKE_AUTH, уже зашифрованный, поэтому ни одна широковещательная передача DHCP не пересекает туннель.

Отсюда два следствия. Во-первых, адрес выбирает отвечающая сторона или любая система авторизации, к которой она обращается, поэтому пул может находиться на шлюзе, в ответе RADIUS или в сопоставлении поставщика идентичности. Во-вторых, атрибут DNS отделён от атрибута адреса. Получение 10.80.0.14 ничего не говорит о том, какой резолвер вернулся и вернулся ли он вообще.

Атрибут маски сети на практике необязателен. Многие развёртывания возвращают только адрес и позволяют клиенту установить маршрут к узлу, поэтому один и тот же пул может выглядеть как /32 на одном клиенте и как /24 на другом.

Где сталкиваются область DHCP локальной сети и пул VPN

Проблемы начинаются, когда оба выдающих указывают на один диапазон. DHCP-сервер для 10.20.30.0/24 ничего не знает о пуле VPN, настроенном для 10.20.30.128/25, поэтому ничто не мешает ему сдать 10.20.30.140 в аренду принтеру, пока шлюз выдаёт тот же адрес удалённому клиенту. Конфликт днями остаётся незаметным, а затем проявляется как периодический дубликат.

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

Объединение туннеля с локальной сетью мостом снимает это разделение. Если схеме действительно нужен один широковещательный домен, конечная точка VPN должна участвовать в тех же решениях о выделении адресов, что и DHCP-сервер, через ретранслятор или общий авторитетный источник, а не выдавать адреса сама.

Докажите, какой процесс владеет адресом

Докажите принадлежность, прежде чем менять диапазон. На клиенте запишите адрес и префикс. В локальной сети поищите в базе аренды. На шлюзе перечислите пулы, которые он настроен выдавать. Адрес, найденный в файле аренды, принадлежит DHCP-серверу, значит туннель соединён мостом или передан через ретранслятор; адрес, найденный только в пуле шлюза, принадлежит конечной точке туннеля.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Запишите четыре вещи, когда ответ станет ясен: какой компонент назначает адрес клиента, какой диапазон для него зарезервирован, как обратный трафик достигает этого диапазона и какие ресурсы его принимают. Эти четыре записи превращают строку виртуального адаптера в эксплуатационный факт.

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

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