Чому два сайти з однією підмережею — не одна мережа LAN

Два офіси обидва використовують 192.168.77.0/24, і хтось пропонує тунель, щоб вони стали однією мережею. Фраза звучить просто і приховує три різні рішення: дві незалежні мережі LAN, які конфліктують, один навмисно розтягнутий через WAN сегмент Ethernet і схема proxy-ARP, яка відповідає за віддалені адреси. Яке саме у вас — визначає, що вузол робить із пакетом, і відповідь видно ще до участі VPN-шлюзу.

Вузол вирішує раніше за маршрутизатор

Вузол з адресою 192.168.77.10/24 порівнює призначення зі своїм префіксом. Усе всередині цього префікса перебуває в прямому каналі, тому вузол сам розв’язує адресу канального рівня призначення. Усе поза ним іде на шлюз за замовчуванням.

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

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

ARP — це питання локального каналу

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

Два пристрої з однаковою адресою погіршують справу: навіть успішне розв’язання не скаже, який із них відповів.

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

Розтягнутий сегмент переносить кадри, а не маршрути

Тунель, що переносить Ethernet і підключений до мостів, робить обидва сайти частиною одного домену канального рівня. Широкомовні ARP-запити доходять до іншого боку, і кожен міст дізнається, де розташовані які MAC-адреси. Документація моста в Linux описує цю межу пересилання на основі MAC.

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

Ціна — більший радіус ураження. Затоплення до невідомих адрес, петлі, роздача DHCP і унікальна адресація — усе потребує одного плану, що охоплює обидва сайти. Коли WAN падає, вузли втрачають трафік, який вважають локальним. Фільтрація на мосту й правила VLAN можуть обмежити, що проходить, але перенесення все одно не обіцяє, що дійде кожен локальний керівний кадр.

Proxy ARP — третє рішення

Маршрутизатор може відповісти на ARP за віддалену адресу й потім маршрутизувати до неї. Це змушує віддалений вузол виглядати для відправника в прямому каналі, не розтягуючи широкомовний домен.

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

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

Обирайте за вимогою, потім перевірте

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

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

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Результат у прямому каналі з невдалим записом сусіда вказує на відсутній шлях канального рівня. Результат via називає шлюз і переносить питання в маршрутизацію. На мосту перевірте таблицю пересилання, щоб побачити, чи MAC вивчено через тунель. Кожен вивід звужує питання проєктування, а не починає його заново.