DHCP përmes një VPN: ta urahimë broadcast-in apo ta përcjellim?

Një laptop i ri në anën tjetër të tunelit nuk merr adresë, ndërsa i njëjti laptop funksionon në selinë qendrore. Supozimi i parë i zakonshëm është se tuneli po bllokon DHCP. Më shpesh broadcast-i nuk ka pasur kurrë rrugë: një klient i pakonfiguruar dërgon në 255.255.255.255, dhe një ruter IP i zakonshëm nuk e përcjell atë paketë. Tuneli po bën saktësisht atë që bën një tunel i rrugëzuar.

Dy modele mund ta ndryshojnë këtë, dhe ato nuk janë ekuivalente. Njëri e transporton broadcast-in; tjetri e përcjell kërkesën.

Broadcast-i nuk e kalon kurrë ruterin

Një klient DHCPv4 pa adresë dërgon nga 0.0.0.0 në adresën e broadcast-it të kufizuar në portat UDP 67 dhe 68. Ajo paketë qëndron në lidhjen e saj sipas modelimit. Një ruter që do ta përcillte do të vërshonte çdo segment që shërben.

Prandaj një tunel i rrugëzuar nga siti në sit lidh rele-n me një server. Ai nuk e zgjeron domenin e broadcast-it të klientit, dhe asnjë rregull firewalls nuk do ta bëjë këtë.

Çfarë zgjeron në të vërtetë një tunel i urahur

Një VPN i urahur qëllimisht mund të transportojë broadcast Ethernet brenda topologjisë së tij të mbështetur, dhe atëherë DHCP mund të kalojë si trafik lokal. Është një opsion real, por është një vendim modelimi i shtresës 2. Po zgjeroni domenin e dështimit dhe kufirin e aksesit bashkë me broadcast-in.

Urahja ndryshon gjithashtu se çfarë mund të arrijnë një stuhi broadcast-i, një skanim ARP ose një server DHCP i rremë. Nëse nuk do ta lidhnit zyrën e largët në të njëjtin komutator, mos e urahni tunelin vetëm për të shpërndarë adresa. Testoni atë rreze ndikimi përpara se ta aktivizoni.

Është një vendim më i madh sesa sigurimi i një adrese, dhe duhet marrë me vetëdije.

Në vend të kësaj përcillni kërkesën

Përgjigja e zakonshme është një rele në rrjetin lokal të klientit. Ai e pranon broadcast-in, e kthen në një kërkesë unicast dhe vendos adresën e tij në fushën e adresës së gateway-it. Serveri përgjigjet në atë adresë të relesë.

Për një zyrë të largët ilustruese, releja qëndron në LAN-in e zyrës dhe serveri arrihet përmes VPN-it të sitit. Konfiguroni fushën për atë zyrë, identitetet e relesë dhe të serverit, dhe rrugën e plotë të kthimit. Lejimi i UDP 67 përmes tunelit nuk i thotë serverit cilin grup të përdorë.

Një rele që përcjell por nuk merr kurrë përgjigje është zakonisht një problem i rrugës së kthimit. Kontrolloni rrugën prapa drejt adresës së relesë përpara se të ndryshoni fushën.

Ndani DHCP nga ARP dhe nga adresimi i tunelit

DHCP ecën mbi UDP/IP. Në Ethernet, një host mund të përdorë edhe ARP për të kontrolluar nëse një adresë kandidate është tashmë në përdorim. Ai kontroll konflikti është një operacion i veçantë lokal i lidhjes, jo transporti i mesazheve DHCP. Të thuash se DHCP është në thelb ARP është gabim; të thuash se të dy nuk lidhen kurrë është shumë e gjerë.

Një klient VPN mund ta marrë adresën e tunelit edhe nga protokolli VPN ose nga grupi i vetë serverit, në vend të një broadcast-i DHCP. Një opsion që e ka DHCP në emër mund të përshkruajë cilësime klienti të shtyra, jo një paketë DHCP të përcjellë. Kontrolloni grupin e serverit përpara se të supozoni se DHCP është përfshirë fare.

Regjistroni rrjetin marrës, pronarin e alokimit, fushën, nëse ekziston një rele, dhe sjelljen e pritur gjatë një ndërprerjeje. Më pas testoni një qira të re dhe një rinovim përmes atij modeli. Nëse dy site mund të shërbejnë të njëjtin grup të pamenaxhuar, keni një konflikt që pret laptop-in e parë në lëvizje.