VPN арқылы DHCP: хабар таратуды көпірмен өткізу ме, әлде реле ме?

Туннельдің арғы жағындағы жаңа ноутбук мекенжай алмайды, ал сол ноутбук бас кеңседе жұмыс істейді. Әдеттегі бірінші болжам — туннель DHCP-ны бөгеп тұр. Көбінесе хабар таратудың жолы мүлдем болмаған: конфигурацияланбаған клиент 255.255.255.255-ке жібереді, ал қарапайым IP маршрутизатор бұл пакетті әрі қарай жібермейді. Туннель маршрутталған туннель жасайтын нәрсенің дәл өзін жасайды.

Екі жоба мұны өзгерте алады және олар баламалы емес. Біреуі хабар таратуды алып жүреді; екіншісі сұранысты реле арқылы береді.

Хабар тарату маршрутизатордан ешқашан өтпейді

Мекенжайы жоқ DHCPv4 клиенті 0.0.0.0-ден шектеулі хабар тарату мекенжайына UDP 67 және 68 порттары арқылы жібереді. Бұл пакет жобасы бойынша өз байланыс желісінде қалады. Оны әрі қарай жіберетін маршрутизатор өзі қызмет көрсететін әрбір сегментті су басқандай толтырар еді.

Сондықтан маршрутталған сайт-сайт туннелі релені серверге қосады. Ол клиенттің хабар тарату доменін кеңейтпейді, және ешбір брандмауэр ережесі оны істей алмайды.

Көпірге қосылған туннель шын мәнінде нені кеңейтеді

Әдейі көпірге қосылған VPN өзінің қолдайтын топологиясы шегінде Ethernet хабар таратуын алып жүре алады, сонда DHCP жергілікті трафик ретінде өте алады. Бұл нақты нұсқа, бірақ 2-қабаттың жобалық шешімі. Сіз хабар таратумен бірге ақау доменін және кіру шекарасын кеңейтіп отырсыз.

Көпір хабар тарату дауылының, ARP скандауының немесе жалған DHCP серверінің қайда жете алатынын да өзгертеді. Егер қашықтағы кеңсені сол коммутаторға қоспайтын болсаңыз, тек мекенжайларды тарату үшін туннельді көпірге айналдырмаңыз. Қоспас бұрын сол әсер радиусын тексеріңіз.

Бұл мекенжай беруден үлкенірек шешім, және оны әдейі қабылдау керек.

Оның орнына сұранысты реле арқылы беріңіз

Әдеттегі жауап — клиенттің жергілікті желісіндегі реле. Ол хабар таратуды қабылдап, оны unicast сұранысқа айналдырады және өз мекенжайын шлюз мекенжайы өрісіне қояды. Сервер сол реле мекенжайына жауап береді.

Мысал ретіндегі қашықтағы кеңсе үшін реле кеңсенің LAN-ында орналасады, ал серверге сайт VPN-ы арқылы жетеді. Сол кеңсе үшін аяны, реле мен сервердің сәйкестіктерін және толық қайту жолын конфигурациялаңыз. Туннель арқылы UDP 67-ге рұқсат беру серверге қай пулды қолдану керектігін айтпайды.

Жіберетін, бірақ ешқашан жауап алмайтын реле әдетте қайту жолының мәселесі. Аяны өзгертуден бұрын реле мекенжайына қарай маршрутты тексеріңіз.

DHCP-ны ARP-тан және туннель мекенжайларынан бөліңіз

DHCP UDP/IP үстінен жүреді. Ethernet-те хост таңдаулы мекенжайдың әлдеқашан қолданылып жатқанын тексеру үшін ARP-ты да пайдалана алады. Бұл қақтығысты тексеру жеке буын-жергілікті операция, DHCP хабарларының тасымалы емес. DHCP негізінен ARP деп айту қате; екеуі ешқашан байланыспайды деп айту тым кең.

VPN клиенті туннель мекенжайын DHCP хабар таратуынан емес, VPN протоколынан немесе сервердің өз пулынан да ала алады. Атында DHCP бар опция реле арқылы берілген DHCP пакетін емес, итерілген клиент параметрлерін сипаттауы мүмкін. DHCP мүлдем қатысады деп есептемес бұрын сервердің пулын тексеріңіз.

Қабылдаушы желіні, бөлу иесін, аяны, реленің бар-жоғын және іркіліс кезінде күтілетін мінез-құлықты жазып алыңыз. Содан кейін сол модель арқылы жаңа жалдау мен жаңартуды тексеріңіз. Егер екі сайт бір басқарылмайтын пулға қызмет көрсете алса, сізде бірінші көшпелі ноутбукты күтіп тұрған қақтығыс бар.