DHCP sa buong VPN: i-bridge ang broadcast o i-relay ito?

Walang nakukuhang address ang bagong laptop sa kabilang dulo ng tunnel, samantalang gumagana ang parehong laptop sa punong tanggapan. Ang karaniwang unang hinala ay hinaharangan ng tunnel ang DHCP. Mas madalas, ang broadcast ay wala talagang daan: nagpapadala ang hindi naka-configure na client sa 255.255.255.255, at hindi ipinapasa ng ordinaryong IP router ang packet na iyon. Ginagawa ng tunnel ang eksaktong ginagawa ng isang routed tunnel.

May dalawang disenyo na makakapagbago nito, at hindi sila magkatumbas. Dinadala ng isa ang broadcast; ipinapasa ng iba ang kahilingan.

Hindi kailanman tumatawid ang broadcast sa router

Ang DHCPv4 client na walang address ay nagpapadala mula 0.0.0.0 patungo sa limitadong broadcast address sa UDP ports 67 at 68. Nananatili ang packet na iyon sa link nito ayon sa disenyo. Ang router na magpapasa nito ay babahain ang bawat segment na pinaglilingkuran nito.

Kaya ang routed na site-to-site tunnel ay nag-uugnay sa relay sa isang server. Hindi nito pinapalawak ang broadcast domain ng client, at wala ring firewall rule na gagawa niyon.

Ano ang aktuwal na pinapalawak ng naka-bridge na tunnel

Ang sadyang naka-bridge na VPN ay makakadala ng Ethernet broadcast sa loob ng sinusuportahang topology nito, at pagkatapos ay makakapasok ang DHCP bilang lokal na trapiko. Tunay na opsyon ito, ngunit desisyon ito sa disenyo ng layer 2. Pinalalawak mo ang domain ng pagkasira at ang hangganan ng access kasama ng broadcast.

Binabago rin ng bridging ang maaabot ng broadcast storm, ARP sweep o mapanlinlang na DHCP server. Kung hindi mo isasaksak ang remote office sa parehong switch, huwag i-bridge ang tunnel para lang mamahagi ng address. Subukan ang radius ng epekto bago ito paganahin.

Mas malaking desisyon ito kaysa sa pagbibigay ng address, at dapat gawin nang sadya.

Sa halip, ipasa ang kahilingan

Ang karaniwang sagot ay isang relay sa lokal na network ng client. Tinatanggap nito ang broadcast, ginagawa itong unicast na kahilingan, at inilalagay ang sariling address sa field ng address ng gateway. Tumutugon ang server sa address ng relay na iyon.

Para sa isang halimbawang remote office, nasa LAN ng opisina ang relay at naaabot ang server sa pamamagitan ng VPN ng site. I-configure ang scope para sa opisinang iyon, ang pagkakakilanlan ng relay at server, at ang kumpletong daan pabalik. Ang pagpapahintulot ng UDP 67 sa tunnel ay hindi nagsasabi sa server kung aling pool ang gagamitin.

Ang relay na nagpapasa ngunit hindi kailanman tumatanggap ng tugon ay karaniwang problema sa daan pabalik. Suriin ang ruta pabalik sa address ng relay bago baguhin ang scope.

Ihiwalay ang DHCP mula sa ARP at sa pag-address ng tunnel

Dumadaan ang DHCP sa UDP/IP. Sa Ethernet, maaari ring gumamit ang host ng ARP upang suriin kung ginagamit na ang isang kandidatong address. Ang pagsusuring iyon ng salungatan ay hiwalay na lokal-sa-link na operasyon, hindi ang transport ng mga mensahe ng DHCP. Mali ang sabihing ang DHCP ay mahalagang ARP; masyadong malawak ang sabihing wala silang kinalaman.

Maaari ring makuha ng VPN client ang address ng tunnel nito mula sa protocol ng VPN o sa pool ng server mismo sa halip na sa broadcast ng DHCP. Ang opsyon na may DHCP sa pangalan ay maaaring naglalarawan ng mga setting ng client na itinulak, hindi ng relay na DHCP packet. Suriin ang pool ng server bago ipagpalagay na kasangkot ang DHCP.

Itala ang network ng tatanggap, ang may-ari ng alokasyon, ang scope, kung may relay, at ang inaasahang pag-uugali habang may outage. Pagkatapos ay subukan ang bagong lease at renewal sa pamamagitan ng modelong iyon. Kung dalawang site ang makapaglilingkod sa parehong hindi pinamamahalaang pool, mayroon kang salungatan na naghihintay sa unang gumagalaw na laptop.