DHCP preko VPN-a: premostiti broadcast ili ga proslijediti?

Novi prijenosnik s druge strane tunela ne dobiva adresu, dok isti prijenosnik radi u sjedištu. Uobičajena prva pretpostavka je da tunel blokira DHCP. Češće broadcast nikada nije imao put: nepodešen klijent šalje na 255.255.255.255, a običan IP usmjerivač ne prosljeđuje taj paket. Tunel radi upravo ono što radi usmjereni tunel.

Dva dizajna mogu to promijeniti i nisu ekvivalentna. Jedan nosi broadcast; drugi prosljeđuje zahtjev.

Broadcast nikada ne prelazi usmjerivač

DHCPv4 klijent bez adrese šalje s 0.0.0.0 na adresu ograničenog broadcasta na UDP portovima 67 i 68. Taj paket po dizajnu ostaje na svom linku. Usmjerivač koji bi ga proslijedio plavio bi svaki segment koji poslužuje.

Zato usmjereni tunel od lokacije do lokacije povezuje relej s poslužiteljem. On ne proširuje broadcast domenu klijenta i nijedno pravilo vatrozida to neće postići.

Što premošteni tunel zapravo proširuje

Namjerno premošten VPN može nositi Ethernet broadcast u okviru svoje podržane topologije, a tada DHCP može prelaziti kao lokalni promet. To je stvarna opcija, ali je dizajnerski izbor sloja 2. Proširujete domenu kvarova i granicu pristupa zajedno s broadcastom.

Premošćivanje također mijenja što broadcast oluja, ARP skeniranje ili lažni DHCP poslužitelj mogu dosegnuti. Ako ne biste udaljeni ured uključili u isti preklopnik, ne premošćujte tunel samo da biste dijelili adrese. Testirajte taj radijus eksplozije prije nego što ga omogućite.

To je veća odluka od dodjele adrese i mora se donijeti svjesno.

Umjesto toga proslijedite zahtjev

Uobičajen odgovor je relej na lokalnoj mreži klijenta. On prima broadcast, pretvara ga u unicast zahtjev i stavlja svoju adresu u polje adrese pristupnika. Poslužitelj odgovara na tu adresu releja.

Za ilustrativni udaljeni ured, relej stoji na LAN-u ureda, a poslužitelj se doseže preko VPN-a lokacije. Konfigurirajte opseg za taj ured, identitete releja i poslužitelja i potpuni povratni put. Dopuštanje UDP 67 kroz tunel ne govori poslužitelju koji bazen koristiti.

Relej koji prosljeđuje ali nikada ne prima odgovor obično je problem povratnog puta. Provjerite rutu natrag do adrese releja prije nego što promijenite opseg.

Odvojite DHCP od ARP-a i od adresiranja tunela

DHCP radi preko UDP/IP-a. Na Ethernetu host može koristiti i ARP da provjeri je li predložena adresa već u upotrebi. Ta provjera sukoba je odvojena lokalna operacija na linku, a ne transport za DHCP poruke. Reći da je DHCP u biti ARP pogrešno je; reći da dvoje nikada nisu povezani preširoko je.

VPN klijent može dobiti adresu tunela i od VPN protokola ili iz vlastitog bazena poslužitelja, umjesto iz DHCP broadcasta. Opcija čije ime sadrži DHCP može opisivati gurnute klijentske postavke, a ne proslijeđeni DHCP paket. Provjerite bazen poslužitelja prije nego što pretpostavite da je DHCP uopće uključen.

Zabilježite mrežu primatelja, vlasnika dodjele, opseg, postoji li relej i očekivano ponašanje tijekom prekida. Zatim testirajte novi zakup i obnovu kroz taj model. Ako dvije lokacije mogu posluživati isti neupravljani bazen, imate sukob koji čeka prvi lutajući prijenosnik.