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

Novi laptop s druge strane tunela ne dobija adresu, dok isti laptop 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 ruter ne prosljeđuje taj paket. Tunel radi upravo ono što radi rutirani tunel.

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

Broadcast nikada ne prelazi ruter

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. Ruter koji bi ga proslijedio plavio bi svaki segment koji opslužuje.

Zato rutirani tunel od lokacije do lokacije povezuje relej sa serverom. On ne proširuje broadcast domenu klijenta i nijedno pravilo firewall-a to neće postići.

Šta premošteni tunel zaista 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 saobraćaj. 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 šta broadcast oluja, ARP skeniranje ili lažni DHCP server mogu dosegnuti. Ako ne biste udaljenu kancelariju 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. Server odgovara na tu adresu releja.

Za ilustrativnu udaljenu kancelariju, relej stoji na LAN-u kancelarije, a server se doseže preko VPN-a lokacije. Konfigurirajte opseg za tu kancelariju, identitete releja i servera i potpuni povratni put. Dozvola UDP 67 kroz tunel ne govori serveru 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 suštini ARP je pogrešno; 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 servera, umjesto iz DHCP broadcasta. Opcija čije ime sadrži DHCP može opisivati gurnute klijentske postavke, a ne proslijeđeni DHCP paket. Provjerite bazen servera prije nego što pretpostavite da je DHCP uopće uključen.

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