DHCP di seluruh VPN: jembatani broadcast atau relay?

Laptop baru di sisi jauh terowongan tidak mendapat alamat, padahal laptop yang sama berfungsi di kantor pusat. Dugaan pertama yang biasa adalah terowongan memblokir DHCP. Lebih sering broadcast tidak pernah punya jalur: klien yang belum dikonfigurasi mengirim ke 255.255.255.255, dan router IP biasa tidak meneruskan paket itu. Terowongan melakukan persis apa yang dilakukan terowongan yang memakai rute.

Dua desain dapat mengubahnya, dan keduanya tidak setara. Satu membawa broadcast; yang lain me-relay permintaan.

Broadcast tidak pernah melewati router

Klien DHCPv4 tanpa alamat mengirim dari 0.0.0.0 ke alamat broadcast terbatas pada port UDP 67 dan 68. Paket itu tetap di tautannya secara desain. Router yang meneruskannya akan membanjiri setiap segmen yang dilayaninya.

Jadi terowongan situs-ke-situs yang dirutekan menghubungkan relay ke server. Itu tidak memperluas domain broadcast klien, dan tidak ada aturan firewall yang akan membuatnya demikian.

Apa yang sebenarnya diperluas terowongan yang dijembatani

VPN yang sengaja dijembatani dapat membawa broadcast Ethernet dalam topologi yang didukungnya, dan kemudian DHCP dapat menyeberang sebagai lalu lintas lokal. Itu pilihan nyata, tetapi merupakan keputusan desain lapisan 2. Anda memperluas domain kegagalan dan batas akses bersama broadcast.

Penjembatanan juga mengubah apa yang dapat dijangkau oleh badai broadcast, pemindaian ARP, atau server DHCP nakal. Jika Anda tidak akan mencolokkan kantor jarak jauh ke sakelar yang sama, jangan jembatani terowongan hanya untuk membagikan alamat. Uji radius dampak itu sebelum Anda mengaktifkannya.

Itu keputusan yang lebih besar daripada menyediakan alamat, dan harus diambil dengan sengaja.

Relay saja permintaannya

Jawaban yang biasa adalah relay di jaringan lokal klien. Relay menerima broadcast, mengubahnya menjadi permintaan unicast, dan menaruh alamatnya sendiri di bidang alamat gateway. Server membalas ke alamat relay itu.

Untuk kantor jarak jauh sebagai ilustrasi, relay berada di LAN kantor dan server dijangkau melalui VPN situs. Konfigurasikan cakupan untuk kantor itu, identitas relay dan server, serta jalur balik lengkap. Mengizinkan UDP 67 melalui terowongan tidak memberi tahu server kumpulan mana yang harus dipakai.

Relay yang meneruskan tetapi tidak pernah menerima balasan biasanya masalah jalur balik. Periksa rute kembali ke alamat relay sebelum Anda mengubah cakupan.

Pisahkan DHCP dari ARP dan dari pengalamatan terowongan

DHCP berjalan di atas UDP/IP. Di Ethernet, host juga dapat menggunakan ARP untuk memeriksa apakah alamat kandidat sudah dipakai. Pemeriksaan konflik itu adalah operasi lokal-tautan yang terpisah, bukan transport untuk pesan DHCP. Mengatakan DHCP pada dasarnya adalah ARP itu salah; mengatakan keduanya tidak pernah berhubungan terlalu luas.

Klien VPN juga dapat memperoleh alamat terowongannya dari protokol VPN atau dari kumpulan server itu sendiri alih-alih dari broadcast DHCP. Opsi yang namanya mengandung DHCP mungkin menjelaskan pengaturan klien yang didorong, bukan paket DHCP yang di-relay. Periksa kumpulan server sebelum Anda menganggap DHCP terlibat sama sekali.

Catat jaringan penerima, pemilik alokasi, cakupan, ada tidaknya relay, dan perilaku yang diharapkan selama gangguan. Lalu uji sewa baru dan pembaruan melalui model itu. Jika dua situs dapat melayani kumpulan tak terkelola yang sama, Anda punya konflik yang menunggu laptop pertama yang berpindah.