Ваш пул VPN — не діапазон DHCP у LAN: чому це ламається

Спокусливий короткий шлях — видавати клієнтам VPN адреси з того самого діапазону, який використовує офісний сервер DHCP, сподіваючись, що все одно все одна мережа. Але це не так. Маршрутизований тунель переносить unicast-пакети між двома кінцями, а пул LAN існує, щоб відповідати на широкомовні запити в фізичному сегменті. Повторне використання номерів робить двох розподільників відповідальними за один адресний простір і залишає зворотний шлях невизначеним.

Два розподільники, один адресний простір

Сервер DHCP у LAN знає, які адреси він здав в оренду і якому MAC-адресі, і захищає їх за допомогою ARP. У сервера VPN свій пул, і про ці оренди він нічого не знає. Жоден не помиляється; їх просто ніколи не знайомили.

Адреса з пулу LAN, яку видає сервер VPN, може вже належати принтеру. Тепер два пристрої претендують на одну адресу в одному префіксі, і таблиця пересилання комутатора вирішує, хто відповість.

Саме з цією несправністю люди стикаються першою: клієнт успішно підключається і потім потрапляє на неправильну машину або потрапляє на правильну з перебоями.

Чому маршрутизатор не роздає адреси VPN

Виявлення DHCP — це широкомовний запит, а широкомовність зупиняється на маршрутизованій межі. Якщо проєкт не об'єднує тунель мостом і не запускає ретранслятор DHCP з відповідними повноваженнями, запит клієнта ніколи не доходить до сервера LAN.

Тому сервер VPN сам призначає адресу: пул у конфігурації сервера, адресу кожному партнеру в налаштуванні WireGuard або адресу, яку проштовхує рівень автентифікації під час розгортання IKEv2. Ці механізми не залежать від бази оренд LAN, і саме тому їм потрібен власний діапазон.

Те саме міркування пояснює, чому зміна області DHCP не виправляє клієнт VPN, який ніколи не отримує адресу. Клієнт не запитує сервер LAN, і жодне редагування області не змусить його запитати.

Перекриття проявляється як конфлікт, а не як повільна мережа

Дві мережі, що спільно використовують префікс без підтримуваного проєкту, — це інша проблема, ніж подвійне володіння, і їх часто плутають. Якщо пул VPN — окремий префікс, перекриття важливе лише тоді, коли маршрут надсилає трафік не в той бік. Якщо пул лежить усередині префікса LAN, конфлікт негайний і локальний.

На практиці ви бачите ARP-відповіді від неправильного пристрою, з'єднання, що скидаються на півдорозі, і клієнта, чию власну адресу вимагає хтось інший. Ніщо з цього не виглядає як проблема маршрутизації, тому виправлення застосовують не на тому рівні. Подвійна оренда легко підтверджується і заважає жити. Вона переживає й перезавантаження, бо обидва розподільники продовжують наполягати на одній адресі.

Зворотний шлях — окрема проблема

Навіть із чистим і окремим пулом хостам LAN треба знати, як відповісти клієнту. Їхній шлюз за замовчуванням — маршрутизатор, і маршрутизатору потрібен маршрут до пулу, що вказує на сервер VPN, якщо проєкт не транслює трафік клієнта.

Прочитайте шлях в обох напрямках, перш ніж щось змінювати. На шлюзі запитайте, який інтерфейс ядро використало б для адреси клієнта; на клієнті запитайте, який маршрут він використовує для адреси LAN.

Ці команди показують рішення про пересилання на шлюзі та записи сусідів, які виявляють дублікат:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Якщо перша команда відповідає інтерфейсом тунелю, зворотний маршрут існує. Якщо вона відповідає інтерфейсом LAN, маршрутизатор вважає, що клієнт на дроті, і спробує виконати для нього ARP.

Мостові проєкти існують, але їх треба вибирати

Об'єднання тунелю з LAN мостом — реальний проєкт, який застосовують, коли клієнти мають отримувати широкомовні повідомлення або їх мають виявляти протоколи, що припускають один сегмент. Він вимагає, щоб сервер володів цією мостовою поведінкою та супутньою обробкою адрес.

Що не працює — це імітація результату копіюванням номерів. Спільний пул без моста дає вам конфлікт без виявлення, а це найгірше з обох варіантів.

Виберіть третій рівень з окремим пулом, якщо тільки застосунку справді не потрібен сегмент, і задокументуйте пул, щоб наступний адміністратор не використав діапазон DHCP знову заради порядку.