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