Защо два обекта с една и съща подмрежа не са една LAN

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

Хостът решава преди маршрутизатора

Хост с адрес 192.168.77.10/24 сравнява дестинацията със своя префикс. Всичко в този префикс е в същия сегмент, затова хостът разрешава директно адреса на каналния слой на дестинацията. Всичко извън него отива към шлюза по подразбиране.

Това решение се взема в стека на хоста, не в тунела. Маршрут, добавен на шлюза, не може да спаси пакет, който хостът никога не изпраща там.

Затова, когато 192.168.77.20 съществува само в другия обект, локалният хост прави ARP за него и не получава отговор. VPN ръкостискането може да е напълно изправно, докато това се проваля. Провалът изглежда като мъртъв хост, а не като проблем с маршрутизацията. Разпознаването на този признак спестява час от отстраняване на проблеми с тунела.

ARP е въпрос за локалния канал

ARP пита кой притежава адрес в този канал и отговорът трябва да дойде от нещо, което чува broadcast-а. Маршрутизатор в другия край на IPsec тунел не го чува, освен ако решението не направи двата обекта един broadcast домейн.

Две устройства с един и същ адрес влошават нещата: дори успешно разрешаване не може да ви каже кое от тях е отговорило.

Дублирането на адреси не е грешка в маршрутизацията и никой маршрут не го поправя. Или обектите се преномерират в различни префикси, или съзнателно стават един канален домейн.

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

Тунел, който пренася Ethernet и е свързан към мостове, прави двата обекта част от един канален домейн. ARP broadcast-ите достигат до другата страна и всеки мост научава къде се намират MAC адресите. Документацията за моста в Linux описва тази граница на препращане на базата на MAC.

Тук отдалеченият шлюз изобщо не маршрутизира между две еднакви подмрежи. Кадрите преминават през подложка, която сама маршрутизира IP, докато мостовете разширяват Ethernet разговора.

Цената е по-голям радиус на поражение. Наводняването за неизвестни дестинации, циклите, DHCP разпределението и уникалната адресация — всичко това изисква един план за двата обекта. Когато WAN падне, хостовете губят трафик, който смятат за локален. Филтрирането на моста и правилата за VLAN могат да ограничат какво преминава, но пренасянето все още не гарантира, че всеки локален контролен кадър ще стигне.

Proxy ARP е трето решение

Маршрутизатор може да отговори на ARP за отдалечен адрес и след това да маршрутизира към него. Това прави отдалечения хост видим в сегмента за подателя, без да разтяга broadcast домейн.

Това е по-тесен инструмент от мостовото свързване: зависи от препращането, обратните маршрути и ясен собственик на всеки адрес.

Той също не прави произволни не-IP протоколи маршрутизируеми и не възпроизвежда Ethernet broadcast домейн. Използвайте го, когато изискването е точно това заместване, а не като пряк път за отложено преномериране.

Избирайте според изискването, после проверете

За обикновен достъп до приложения между офиси различните префикси и явните маршрути дават по-ясна граница. Правете мост, когато изискването е наистина съседство на каналния слой. Преномерирайте, когато единствената причина за общия префикс е, че никой още не го е направил.

Потвърдете кое решение всъщност имате, като попитате хост какво прави с дестинацията:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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