Вашият VPN пул не е DHCP диапазонът на LAN: защо се чупи

Маршрутизираният тунел не е Ethernet сегмент. Изберете пул, който не се застъпва с LAN, после дайте на LAN обратен маршрут, преди клиентите да се опитат да го достигнат.

Изкушаващото кратко решение е да давате на VPN клиентите адреси от същия диапазон, който ползва офисният DHCP сървър, с идеята, че всичко все пак е една мрежа. Не е. Маршрутизираният тунел пренася unicast пакети между две крайни точки, докато LAN пулът съществува, за да отговаря на broadcast заявки във физически сегмент. Повторното използване на числата слага два разпределителя отговорни за едно адресно пространство и оставя обратния път неопределен.

Два разпределителя, едно адресно пространство

LAN DHCP сървърът знае кои адреси е отдал под наем и на кой MAC адрес, и ги защитава с ARP. VPN сървърът има свой пул и не знае нищо за тези наеми. Никой от двата не греши; просто никога не са били запознати.

Адрес от LAN пула, който VPN сървърът раздава, може вече да принадлежи на принтер. Сега две устройства претендират за един адрес в една и съща префиксна мрежа и таблицата за препращане на суича решава кое ще отговори.

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

Защо рутерът не раздава VPN адреси

Откриването на DHCP е broadcast, а broadcast-ите спират на маршрутизирана граница. Освен ако дизайнът не мости тунела или не пуска DHCP релей със съответните правомощия, заявката на клиента никога не стига до LAN сървъра.

Затова VPN сървърът сам задава адреса: пул в конфигурацията на сървъра, адрес за всеки партньор при WireGuard, или адрес, подаден от слоя за удостоверяване при внедряване на IKEv2. Тези механизми са независими от базата с наеми на LAN, и точно затова им трябва собствен диапазон.

Същата логика обяснява защо промяната на DHCP обхвата не поправя VPN клиент, който никога не получава адрес. Клиентът не пита LAN сървъра и никакво редактиране на обхвата не го кара да попита.

Застъпването се проявява като конфликт, не като бавна мрежа

Две мрежи, които споделят префикс без поддържан дизайн, са различен проблем от двойното собственост, и често се бъркат. Ако VPN пулът е отделен префикс, застъпването има значение само когато маршрут изпраща трафик към грешната страна. Ако пулът е вътре в LAN префикса, конфликтът е незабавен и локален.

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

Обратният път е отделен проблем

Дори с чист и отделен пул, LAN хостовете трябва да знаят как да отговорят на клиент. Шлюзът им по подразбиране е рутерът, а рутерът се нуждае от маршрут за пула към VPN сървъра, освен ако дизайнът не трансформира клиентския трафик.

Прочетете пътя в двете посоки, преди да промените нещо. На шлюза попитайте кой интерфейс би използвало ядрото за адрес на клиент; на клиента попитайте кой маршрут използва за LAN адрес.

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

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Ако първата команда отговори с тунелния интерфейс, обратният маршрут съществува. Ако отговори с LAN интерфейса, рутерът вярва, че клиентът е на кабела и ще се опита да направи ARP за него.

Мостовите дизайни съществуват, но трябва да бъдат избрани

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

Това, което не работи, е имитирането на резултата чрез копиране на числа. Споделен пул без мост ви дава конфликта без откриването, което е най-лошото от двете подредби.

Изберете трети слой с отделен пул, освен ако приложението наистина не се нуждае от сегмента, и документирайте пула, за да не използва следващият администратор DHCP диапазона отново заради подредба.

Подобни статии