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 поправя една конкретна връзка; маршрутизираният пул премахва нуждата от тази поправка. Запишете кой сте избрали и защо, и следващият човек няма да трябва да го открива наново от неуспешен запис за съсед.