DHCP skozi VPN: premostiti broadcast ali ga posredovati?

Nov prenosnik na drugi strani tunela ne dobi naslova, medtem ko isti prenosnik v sedežu deluje. Običajna prva domneva je, da tunel blokira DHCP. Pogosteje broadcast nikoli ni imel poti: nenastavljen odjemalec pošilja na 255.255.255.255, običajni usmerjevalnik IP pa tega paketa ne posreduje. Tunel počne natanko to, kar počne usmerjen tunel.

Dve zasnovi lahko to spremenita in nista enakovredni. Ena prenaša broadcast; druga posreduje zahtevo.

Broadcast nikoli ne prečka usmerjevalnika

Odjemalec DHCPv4 brez naslova pošilja z 0.0.0.0 na omejeni broadcast naslov na vratih UDP 67 in 68. Ta paket po zasnovi ostane na svoji povezavi. Usmerjevalnik, ki bi ga posredoval, bi preplavil vsak segment, ki ga oskrbuje.

Zato usmerjen tunel med lokacijama poveže posredovalnik s strežnikom. Ne širi broadcast domene odjemalca in nobeno pravilo požarnega zidu tega ne bo doseglo.

Kaj premosten tunel dejansko razširi

Namenoma premosten VPN lahko prenaša Ethernet broadcast v okviru svoje podprte topologije in takrat lahko DHCP preide kot lokalni promet. To je resnična možnost, a je zasnovna odločitev ravni 2. Širite domeno napak in mejo dostopa skupaj z broadcastom.

Premostitev spremeni tudi, kam lahko sežejo broadcast nevihta, skeniranje ARP ali lažni strežnik DHCP. Če pisarne na daljavo ne bi priključili na isto stikalo, tunela ne premestite samo zato, da bi delili naslove. Preizkusite ta polmer vpliva, preden ga omogočite.

To je večja odločitev od zagotavljanja naslova in sprejeti jo je treba zavestno.

Namesto tega posredujte zahtevo

Običajen odgovor je posredovalnik v lokalnem omrežju odjemalca. Prejme broadcast, spremeni ga v zahtevo unicast in vstavi svoj naslov v polje naslova prehoda. Strežnik odgovori na ta naslov posredovalnika.

Za ponazoritveno pisarno na daljavo posredovalnik stoji v LAN-u pisarne, strežnik pa je dosegljiv prek VPN lokacije. Nastavite obseg za to pisarno, identiteti posredovalnika in strežnika ter celotno povratno pot. Dovoljenje UDP 67 skozi tunel strežniku ne pove, kateri sklad naj uporabi.

Posredovalnik, ki posreduje, a nikoli ne prejme odgovora, je običajno težava povratne poti. Preden spremenite obseg, preverite pot nazaj do naslova posredovalnika.

Ločite DHCP od ARP in od naslavljanja tunela

DHCP teče prek UDP/IP. V Ethernetu lahko gostitelj uporabi tudi ARP, da preveri, ali je kandidatni naslov že v uporabi. To preverjanje konflikta je ločena lokalna operacija na povezavi, ne prenos sporočil DHCP. Reči, da je DHCP v bistvu ARP, je napačno; reči, da ta dva nikoli nista povezana, je preširoko.

Odjemalec VPN lahko naslov tunela dobi tudi iz protokola VPN ali iz lastnega sklada strežnika, ne iz broadcasta DHCP. Možnost, katere ime vsebuje DHCP, lahko opisuje potisnjene nastavitve odjemalca, ne posredovanega paketa DHCP. Preverite sklad strežnika, preden domnevate, da je DHCP sploh vpleten.

Zabeležite ciljno omrežje, lastnika dodelitve, obseg, ali posredovalnik obstaja, in pričakovano vedenje med izpadom. Nato preizkusite novo najemnino in podaljšanje po tem modelu. Če lahko dve lokaciji oskrbujeta isti neupravljani sklad, imate konflikt, ki čaka na prvi potujoči prenosnik.