Чому хост у локальній мережі надсилає ARP для адреси клієнта OpenVPN

Проблеми доступності між хостом у локальній мережі та клієнтом VPN часто сягають самого плану адресації. Дайте цьому хосту інтерфейс на 10.0.100.0/22, і він вважатиме кожну адресу від 10.0.100.0 до 10.0.103.255 підключеною безпосередньо, включно з пулом клієнтів, тихо розміщеним на 10.0.101.0/24. Відповідь ніколи не йде на маршрутизатор, бо з погляду хоста маршрутизатор не задіяний. Пакет адресовано сусідові й запитано на дроті.

Цей механізм стоїть за цілою родиною повідомлень: тунель піднято, у сервера є маршрут, а хост у локальній мережі досі не може дістатися клієнта.

Префікс /22, що поглинає /24

Читайте префікс як діапазон, а не як рядок. Префікс /22 містить 1024 адреси, а 10.0.100.0/22 простягається від 10.0.100.0 до 10.0.103.255, тож пул на 10.0.101.0/24 лежить цілком усередині. Помилка переживає перегляд, бо перші октети пулу виглядають інакше, ніж перші октети локальної мережі, і лише третій октет викриває вкладеність. Запишіть обидва діапазони в числах, перш ніж оголошувати їх окремими.

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

Пряме з'єднання означає ARP, а не маршрутизацію

Коли хост з інтерфейсом /22 надсилає на 10.0.101.25, ядро порівнює отримувача з префіксом інтерфейсу і знаходить збіг. Пакет стає пошуком сусіда, а не маршрутизованим пакетом, а в Ethernet пошук сусіда — це ARP-запит для цієї адреси. Якщо адреса належить клієнту VPN за маршрутизованим шлюзом, жоден хост у локальній мережі нею не володіє, тож запит лишається без відповіді, а пакети відкидаються. Тунель не винний, і клієнт ніколи не бачить трафік.

Тому збій виглядає асиметричним і подеколи переривчастим. Хост VPN часто дістає локальну мережу, бо його власні маршрути вказують у потрібний бік, тоді як хост у локальній мережі не може відповісти, і будь-яке кешування застарілого запису ARP змушує симптом мерехтіти.

TUN, TAP і що несе кожен

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

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

Спроєктуйте пул, що не може перекриватися

Виберіть пул поза кожним підключеним префіксом і кожним анонсованим префіксом майданчика, потім додайте маршрути, які роблять його досяжним в обидва боки. Діапазон на кшталт 10.8.0.0/24 у невикористаній частині плану легко обдумати, а локальна мережа, якій треба до нього дістатися, отримує статичний маршрут, що вказує на сервер VPN. Змінюйте разом виділення, анонсовані маршрути, дозволені адреси джерел і правила брандмауера, бо вони описують один проєкт, а не чотири налаштування.

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

Для приймання використайте реально призначену адресу справжнього клієнта і справжній запит застосунку з хоста в локальній мережі, потім підтвердьте, що відповідь іде через запланований шлюз, а не по дроту.