Сіздің VPN пулыңыз LAN-ның DHCP ауқымы емес: неге бұл бұзылады

Азғырғыш қысқа жол — VPN клиенттеріне кеңсе DHCP сервері қолданатын сол ауқымнан мекенжайлар беру, бәрібір бәрі бір желі деген болжаммен. Бірақ олай емес. Маршрутталған туннель екі шет арасында unicast пакеттерді тасымалдайды, ал LAN пулы физикалық сегменттегі broadcast сұраныстарына жауап беру үшін бар. Нөмірлерді қайта пайдалану екі бөлгішті бір мекенжай кеңістігіне жауапты етіп, қайтару жолын анықталмаған күйде қалдырады.

Екі бөлгіш, бір мекенжай кеңістігі

LAN-ның DHCP сервері қай мекенжайларды қандай MAC мекенжайына жалға бергенін біледі және оларды ARP арқылы қорғайды. VPN серверінің өз пулы бар және ол жалдаулар туралы ештеңе білмейді. Екеуі де қате емес; оларды жай ғана бір-бірімен таныстырмаған.

VPN сервері LAN пулынан беретін мекенжай бұрыннан принтерге тиесілі болуы мүмкін. Енді екі құрылғы бір префиксте бір мекенжайға таласады, ал коммутатордың жіберу кестесі қайсысы жауап беретінін шешеді.

Бұл — адамдар бірінші кездесетін ақау: сәтті қосылып, кейін дұрыс емес машинаға жететін клиент, немесе дұрыс машинаға үзіліспен жететін клиент.

Неге маршрутизатор 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 ауқымын қайта пайдаланбайды.