DHCP merentas VPN: jambat siaran atau relay?

Komputer riba baharu di sebelah jauh terowong tidak mendapat alamat, sedangkan komputer riba yang sama berfungsi di ibu pejabat. Tekaan pertama yang biasa ialah terowong menyekat DHCP. Lebih kerap siaran tidak pernah mempunyai laluan: klien yang belum dikonfigurasikan menghantar ke 255.255.255.255, dan penghala IP biasa tidak memajukan paket itu. Terowong melakukan tepat apa yang dilakukan terowong yang dihalakan.

Dua reka bentuk boleh mengubahnya, dan kedua-duanya tidak setara. Satu membawa siaran; satu lagi me-relay permintaan.

Siaran tidak pernah melintasi penghala

Klien DHCPv4 tanpa alamat menghantar dari 0.0.0.0 ke alamat siaran terhad pada port UDP 67 dan 68. Paket itu kekal pada pautannya mengikut reka bentuk. Penghala yang memajukannya akan membanjiri setiap segmen yang dilayaninya.

Jadi terowong tapak-ke-tapak yang dihalakan menyambungkan relay kepada pelayan. Ia tidak meluaskan domain siaran klien, dan tiada peraturan tembok api akan menjadikannya begitu.

Apa yang sebenarnya diluaskan oleh terowong yang dijambat

VPN yang dijambat secara sengaja boleh membawa siaran Ethernet dalam topologi yang disokongnya, dan kemudian DHCP boleh melintas sebagai trafik tempatan. Itu pilihan sebenar, tetapi ia keputusan reka bentuk lapisan 2. Anda meluaskan domain kegagalan dan sempadan akses bersama siaran.

Penjambatan juga mengubah apa yang boleh dicapai oleh badai siaran, imbasan ARP atau pelayan DHCP palsu. Jika anda tidak akan memasang pejabat jauh pada suis yang sama, jangan jambat terowong itu semata-mata untuk mengagihkan alamat. Uji jejari kesan itu sebelum anda mengaktifkannya.

Ia keputusan yang lebih besar daripada membekalkan alamat, dan ia harus dibuat secara sedar.

Relay permintaan itu sebagai ganti

Jawapan biasa ialah relay pada rangkaian tempatan klien. Ia menerima siaran, menukarnya menjadi permintaan unicast, dan meletakkan alamatnya sendiri dalam medan alamat gerbang. Pelayan membalas ke alamat relay itu.

Untuk pejabat jauh sebagai contoh, relay terletak pada LAN pejabat dan pelayan dicapai melalui VPN tapak. Konfigurasikan skop untuk pejabat itu, identiti relay dan pelayan, serta laluan pulang yang lengkap. Membenarkan UDP 67 melalui terowong tidak memberitahu pelayan kolam mana yang hendak digunakan.

Relay yang memajukan tetapi tidak pernah menerima balasan biasanya masalah laluan pulang. Semak laluan kembali ke alamat relay sebelum anda menukar skop.

Asingkan DHCP daripada ARP dan daripada pengalamatan terowong

DHCP berjalan di atas UDP/IP. Pada Ethernet, hos juga boleh menggunakan ARP untuk menyemak sama ada alamat calon sudah digunakan. Semakan konflik itu ialah operasi setempat-pautan yang berasingan, bukan pengangkutan bagi mesej DHCP. Mengatakan DHCP pada dasarnya ialah ARP adalah salah; mengatakan kedua-duanya tidak pernah berkaitan terlalu luas.

Klien VPN juga boleh mendapatkan alamat terowongnya daripada protokol VPN atau kolam pelayan itu sendiri dan bukan daripada siaran DHCP. Pilihan yang namanya mengandungi DHCP mungkin menerangkan tetapan klien yang ditolak, bukan paket DHCP yang di-relay. Semak kolam pelayan sebelum anda menganggap DHCP terlibat sama sekali.

Catat rangkaian penerima, pemilik peruntukan, skop, sama ada relay wujud, dan tingkah laku dijangka semasa gangguan. Kemudian uji pajakan baharu dan pembaharuan melalui model itu. Jika dua tapak boleh melayani kolam tidak terurus yang sama, anda mempunyai konflik yang menunggu komputer riba pertama yang berpindah.