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

Novi laptop s druge strane tunela ne dobija adresu, a isti laptop radi u sedištu. Prva uobičajena 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 prosleđuje taj paket. Tunel radi tačno ono što radi rutirani tunel.

Dva dizajna to mogu promeniti i nisu jednaka. Jedan nosi broadcast; drugi prosleđuje zahtev.

Broadcast nikada ne prelazi ruter

DHCPv4 klijent bez adrese šalje sa 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 prosledio plavio bi svaki segment koji opslužuje.

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

Šta premošćen tunel zapravo proširuje

Namerno premošćen VPN može nositi Ethernet broadcast u okviru svoje podržane topologije, a tada DHCP može preći kao lokalni saobraćaj. To je stvarna opcija, ali je dizajnerski izbor sloja 2. Proširujete domen kvarova i granicu pristupa zajedno sa broadcastom.

Premošćavanje menja i to šta broadcast oluja, ARP skeniranje ili lažni DHCP server mogu dosegnuti. Ako ne biste udaljenu kancelariju uključili u isti prekidač, ne premošćujte tunel samo da biste delili adrese. Testirajte taj radijus eksplozije pre nego što ga omogućite.

To je veća odluka od dodele adrese i mora se doneti svesno.

Umesto toga prosledite zahtev

Uobičajen odgovor je relej na lokalnoj mreži klijenta. On prima broadcast, pretvara ga u unicast zahtev 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. Konfigurišite 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 prosleđuje ali nikada ne prima odgovor obično je problem povratnog puta. Proverite rutu natrag do adrese releja pre nego što promenite 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 proveri da li je predložena adresa već u upotrebi. Ta provera 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 sopstvenog bazena servera, umesto iz DHCP broadcasta. Opcija čije ime sadrži DHCP može opisivati gurnuta klijentska podešavanja, a ne prosleđeni DHCP paket. Proverite bazen servera pre nego što pretpostavite da je DHCP uopšte uključen.

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