DHCP преко VPN-а: премостити broadcast или га проследити?

Нови лаптоп са друге стране тунела не добија адресу, док исти лаптоп ради у седишту. Прва уобичајена претпоставка је да тунел блокира DHCP. Чешће broadcast никада није имао пут: неподешен клијент шаље на 255.255.255.255, а обичан IP рутер не прослеђује тај пакет. Тунел ради тачно оно што ради рутирани тунел.

Два дизајна то могу променити и нису једнака. Један носи broadcast; други прослеђује захтев.

Broadcast никада не прелази рутер

DHCPv4 клијент без адресе шаље са 0.0.0.0 на адресу ограниченог broadcast-а на UDP портовима 67 и 68. Тај пакет по дизајну остаје на свом линку. Рутер који би га проследио плавио би сваки сегмент који опслужује.

Зато рутирани тунел од локације до локације повезује релеј са сервером. Он не проширује broadcast домен клијента, и ниједно правило заштитног зида то неће постићи.

Шта премошћен тунел заиста проширује

Намерно премошћен VPN може носити Ethernet broadcast у оквиру своје подржане топологије, а тада DHCP може прећи као локални саобраћај. То је стварна опција, али је дизајнерски избор слоја 2. Проширујете домен кварова и границу приступа заједно са broadcast-ом.

Премошћавање мења и то шта broadcast олуја, ARP скенирање или лажни DHCP сервер могу достићи. Ако не бисте удаљену канцеларију укључили у исти прекидач, не премошћујте тунел само да бисте делили адресе. Тестирајте тај радијус експлозије пре него што га омогућите.

То је већа одлука од доделе адресе и мора се донети свесно.

Уместо тога проследите захтев

Уобичајен одговор је релеј на локалној мрежи клијента. Он прима broadcast, претвара га у unicast захтев и ставља своју адресу у поље адресе приступника. Сервер одговара на ту адресу релеја.

За илустративну удаљену канцеларију, релеј стоји на LAN-у канцеларије, а сервер се достиже преко VPN-а локације. Конфигуришите опсег за ту канцеларију, идентитете релеја и сервера и потпуни повратни пут. Дозвола UDP 67 кроз тунел не говори серверу који базен користити.

Релеј који прослеђује али никада не прима одговор обично је проблем повратног пута. Проверите руту назад до адресе релеја пре него што промените опсег.

Одвојите DHCP од ARP-а и од адресирања тунела

DHCP ради преко UDP/IP-а. На Ethernet-у домаћин може користити и ARP да провери да ли је предложена адреса већ у употреби. Та провера сукоба је одвојена локална операција на линку, а не транспорт за DHCP поруке. Рећи да је DHCP у суштини ARP је погрешно; рећи да двоје никада нису повезани прешироко је.

VPN клијент може добити адресу тунела и од VPN протокола или из сопственог базена сервера, уместо из DHCP broadcast-а. Опција чије име садржи DHCP може описивати гурнута клијентска подешавања, а не прослеђени DHCP пакет. Проверите базен сервера пре него што претпоставите да је DHCP уопште укључен.

Забележите мрежу примаоца, власника доделе, опсег, постоји ли релеј и очекивано понашање током прекида. Затим тестирајте нови закуп и обнову кроз тај модел. Ако две локације могу опслуживати исти неуправљани базен, имате сукоб који чека први лутајући лаптоп.