VPN-клієнт з адресою LAN не перебуває в LAN

Клієнт підключається, отримує 10.50.0.200 і не може досягти сервера за адресою 10.50.0.20, хоча обидва номери лежать в одній /24. Переконання, що стоїть за цією конфігурацією, полягає в тому, що адреса з префікса LAN робить клієнта частиною LAN. Не робить. Клієнт перебуває на з’єднанні точка-точка, сервер вважає призначення локальним, а частина, якої бракує, — це відповідь сусіда, яку ніхто не надсилає.

Міф: однаковий префікс означає той самий сегмент

Префікс адреси каже хосту, які призначення він досягає безпосередньо, а яким потрібен маршрутизатор. Він не каже хосту, як призначення фізично підключене, і вже точно не гарантує, що призначення зможе відповісти на запит канального рівня. Це різні питання, на які відповідають різні таблиці на хості. Маска відповідає на перше, таблиця сусідів на друге, і лише перше перебуває під вашим контролем з боку VPN.

Коли сервер надсилає на 10.50.0.200, він порівнює призначення зі своєю маскою, вирішує, що адреса є on-link, і запитує локальний сегмент про апаратну адресу, якій вона належить. Цей запит виходить через інтерфейс Ethernet, а VPN-клієнта там немає, щоб його почути.

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

Що локальний хост насправді робить з адресою

Поведінку легко спостерігати, і це варто зробити до будь-яких змін. Подивіться на хості LAN у таблицю сусідів після спроби досягти клієнта: неповний або невдалий запис — це весь діагноз в одному рядку. Цей рядок також каже, що несправність локальна для сегмента, а не десь усередині тунелю.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Пошук маршруту повідомить призначення як on-link через інтерфейс Ethernet, і це саме проблема. Якщо запис сусіда залишається неповним, поки сеанс VPN активний, ви підтвердили, що частина, якої бракує, — це розв’язання на канальному рівні, а не маршрутизація чи політика міжмережевого екрана.

Виконайте ту саму перевірку з хоста в іншій підмережі та порівняйте. Хосту, який досягає клієнта через маршрутизатор, запис сусіда взагалі не потрібен, і ця різниця — рішення проєктування в мініатюрі.

Як proxy ARP забезпечує наступний крок

proxy ARP змушує шлюз відповідати на запит канального рівня від імені призначення, до якого він може дістатися через інший інтерфейс. Хост у LAN отримує апаратну адресу, надсилає кадр шлюзу, і шлюз передає пакет у сеанс VPN. З погляду хоста клієнт просто виглядає так, ніби він за шлюзом. У конфігурації клієнта нічого не змінюється.

Документація RouterOS щодо ARP від MikroTik описує таке застосування для dial-in клієнтів, які позичають адресний простір підключеної LAN. Механізм — це виправлення розв’язання сусідів, і він працює, бо шлюз справді перебуває на обох шляхах.

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

Уважно читайте назви режимів платформи. RouterOS розрізняє proxy-arp і local-proxy-arp, і другий обробляє трафік, який входить і виходить через той самий інтерфейс. Це не взаємозамінні написи, і вмикання обох без розбору — не короткий шлях.

Чого proxy ARP вам не дає

Він не забезпечує виявлення через broadcast чи multicast. Клієнт, якому потрібно знайти службу через broadcast, усе одно зазнає невдачі, бо шлюз передає unicast у сеанс і не робить клієнта членом домену broadcast мережі LAN. Протоколи виявлення, що покладаються на broadcast, — часте джерело повідомлень про те, що одне працює, а інше ні, у проєктах з позиченими адресами.

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

І він не знімає потреби узгодження з власником LAN. Запис proxy ARP, який дивує власника плану адрес, — це інцидент підтримки, що чекає на спокійний тиждень.

Порівняння з окремим маршрутизованим пулом

Альтернатива — дати VPN-клієнтам власний префікс і дозволити хостам LAN маршрутизувати до нього. Тоді сервер надсилає off-link відповіді своєму шлюзу, шлюз маршрутизує префікс до кінцевої точки VPN, і на сегменті LAN розв’язання сусідів взагалі не потрібне. Це менше рухомих частин, ніж позичена адреса плюс відповідь proxy.

Такий проєкт легше обміркувати й легше перевірити, бо діапазон клієнтів видимо відокремлений від діапазону LAN. Він коштує маршруту, зворотного шляху та правила доступу — тих самих речей, яких проєкт із proxy ARP потребує в менш очевидному місці.

Вибирайте між моделями свідомо, а не випадково. proxy ARP виправляє одне конкретне відношення; маршрутизований пул усуває потребу в цьому виправленні. Запишіть, що ви обрали і чому, і наступній людині не доведеться відкривати це заново з невдалого запису сусіда.