Вашиот VPN базен не е DHCP опсегот на 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 опсегот повторно поради уредност.