Адреса 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, а це інша несправність, ніж у пула, який видає адресу, вже зайняту локальною мережею.

Схожі статті