Ваш пул VPN — гэта не дыяпазон DHCP у LAN: чаму гэта ламаецца

Спакуслівы кароткі шлях — выдаваць кліентам VPN адрасы з таго ж дыяпазону, які выкарыстоўвае офісны сервер DHCP, зыходзячы з думкі, што ўсё гэта ўсё роўна адна сетка. Але гэта не так. Маршрутызаваны тунель пераносіць unicast-пакеты паміж двума канцавымі пунктамі, а пул LAN існуе, каб адказваць на шырокавяшчальныя запыты ў фізічным сегменце. Паўторнае выкарыстанне нумароў робіць двух размеркавальнікаў адказнымі за адну адрасную прастору і пакідае зваротны шлях невызначаным.

Два размеркавальнікі, адна адрасная прастора

Сервер DHCP у LAN ведае, якія адрасы ён здаў у арэнду і якому MAC-адрасу, і абараняе іх з дапамогай ARP. Сервер VPN мае свой пул і нічога не ведае пра гэтыя арэнды. Ні адзін з іх не памыляецца; іх проста ніколі не знаёмілі.

Адрас з пула LAN, які выдае сервер VPN, можа ўжо належаць прынтару. Цяпер дзве прылады прэтэндуюць на адзін адрас у адным прэфіксе, і табліца перасылкі камутатара вырашае, якая з іх адкажа.

Менавіта з гэтай збоем людзі сутыкаюцца першым: кліент паспяхова падключаецца, а затым трапляе на няправільную машыну або трапляе на правільную з перапынкамі.

Чаму маршрутызатар не выдае адрасы VPN

Выяўленне DHCP — гэта шырокае вяшчанне, а шырокае вяшчанне спыняецца на маршрутызаванай мяжы. Калі праект не мастуе тунель або не запускае рэлей 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 — гэта рэальны праект, які выкарыстоўваецца, калі кліенты павінны атрымліваць шырокавяшчальныя паведамленні або быць выяўленымі пратаколамі, якія мяркуюць адзін сегмент. Ён патрабуе, каб сервер валодаў гэтым паводзінамі масціравання і звернутай з імі апрацоўкай адрасоў.

Што не працуе, дык гэта імітацыя выніку шляхам капіравання нумароў. Агульны пул без моста дае вам канфлікт без выяўлення, што з'яўляецца найгоршым з абодвух варыянтаў.

Выберыце трэці ўзровень з асобным пулам, калі толькі праграма сапраўды не патрабуе сегмента, і задокументуйце пул, каб наступны адміністратар не выкарыстаў дыяпазон DHCP зноў дзеля акуратнасці.