Kumpulan alamat VPN Anda bukan rentang DHCP LAN: mengapa ini rusak

Jalan pintas yang menggiurkan adalah memberikan alamat dari rentang yang sama dengan yang dipakai server DHCP kantor kepada klien VPN, dengan anggapan bahwa semuanya tetap satu jaringan. Tidak. Tunnel yang dirutekan membawa paket unicast antara dua titik akhir, sementara kumpulan alamat LAN ada untuk menjawab permintaan siaran pada segmen fisik. Memakai ulang angka yang sama menempatkan dua pengalokasi bertanggung jawab atas satu ruang alamat dan membiarkan jalur balik tidak terdefinisi.

Dua pengalokasi, satu ruang alamat

Server DHCP LAN tahu alamat mana yang telah disewakannya dan ke alamat MAC mana, dan mempertahankannya dengan ARP. Server VPN punya kumpulan sendiri dan tidak tahu apa pun tentang sewa itu. Keduanya tidak salah; keduanya memang belum pernah diperkenalkan.

Alamat dari kumpulan LAN yang dibagikan server VPN bisa jadi sudah milik sebuah printer. Sekarang dua perangkat mengklaim satu alamat pada prefiks yang sama, dan tabel penerusan switch memutuskan mana yang menjawab.

Itulah kegagalan yang pertama ditemui orang: klien yang berhasil terhubung lalu mencapai mesin yang salah, atau mencapai mesin yang benar secara berkala.

Mengapa router tidak membagikan alamat VPN

Penemuan DHCP adalah siaran, dan siaran berhenti di batas yang dirutekan. Kecuali rancangan menjembatani tunnel atau menjalankan relai DHCP dengan wewenang yang sesuai, permintaan klien tidak pernah sampai ke server LAN.

Karena itu server VPN menetapkan alamatnya sendiri: kumpulan alamat dalam konfigurasi server, satu alamat per peer dalam pemasangan WireGuard, atau alamat yang didorong lapisan autentikasi dalam penerapan IKEv2. Mekanisme itu independen dari basis data sewa LAN, dan itulah tepatnya alasan mereka memerlukan rentang sendiri.

Penalaran yang sama menjelaskan mengapa mengubah cakupan DHCP tidak memperbaiki klien VPN yang tidak pernah mendapat alamat. Klien tidak bertanya kepada server LAN, dan tidak ada penyuntingan cakupan yang membuatnya bertanya.

Tumpang tindih muncul sebagai konflik, bukan sebagai jaringan lambat

Dua jaringan yang berbagi prefiks tanpa rancangan yang didukung adalah masalah berbeda dari kepemilikan ganda, dan keduanya sering dikacaukan. Jika kumpulan VPN adalah prefiks terpisah, tumpang tindih hanya berarti ketika suatu rute mengirim lalu lintas ke sisi yang salah. Jika kumpulan berada di dalam prefiks LAN, konfliknya langsung dan lokal.

Dalam praktik Anda melihat balasan ARP dari perangkat yang salah, koneksi yang ter-reset di tengah jalan, dan klien yang alamatnya diklaim orang lain. Tidak satu pun tampak seperti masalah perutean, karena itulah perbaikannya diterapkan pada lapisan yang salah. Sewa ganda mudah dipastikan dan menjengkelkan untuk dijalani. Sewa itu juga bertahan setelah reboot, karena kedua pengalokasi terus bersikeras pada alamat yang sama.

Jalur balik adalah masalah tersendiri

Bahkan dengan kumpulan yang bersih dan terpisah, host LAN perlu tahu cara menjawab klien. Gateway bawaan mereka adalah router, dan router memerlukan rute untuk kumpulan itu yang menunjuk ke server VPN, kecuali rancangan menerjemahkan lalu lintas klien sebagai gantinya.

Baca jalurnya pada kedua arah sebelum mengubah apa pun. Di gateway, tanyakan antarmuka mana yang akan dipakai kernel untuk alamat klien; di klien, tanyakan rute mana yang dipakainya untuk alamat LAN.

Perintah ini menunjukkan keputusan penerusan di gateway dan entri tetangga yang mengungkap duplikat:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Jika perintah pertama menjawab dengan antarmuka tunnel, rute baliknya ada. Jika menjawab dengan antarmuka LAN, router menganggap klien ada di kabel dan akan mencoba ARP untuknya.

Rancangan dijembatani memang ada, tetapi harus dipilih

Menjembatani tunnel ke LAN adalah rancangan nyata, dipakai ketika klien harus menerima siaran atau harus ditemukan oleh protokol yang menganggap satu segmen. Rancangan itu menuntut server memiliki perilaku penjembatanan tersebut dan penanganan alamat yang menyertainya.

Yang tidak berhasil adalah meniru hasilnya dengan menyalin angka. Kumpulan bersama tanpa jembatan memberi Anda konflik tanpa penemuan, yang merupakan yang terburuk dari kedua pengaturan.

Pilih lapisan tiga dengan kumpulan terpisah kecuali aplikasi benar-benar membutuhkan segmen itu, dan dokumentasikan kumpulan tersebut agar administrator berikutnya tidak memakai ulang rentang DHCP demi kerapian.