Alamat VPN versus sewa DHCP LAN: siapa yang memberikan IP terowongan?

Hubungkan klien dan lihat adaptor, bukan ikon Wi-Fi. Alamat seperti 10.80.0.14 bisa berada di terowongan padahal tidak ada server DHCP di LAN kantor yang pernah mencatat sewa itu. Proses yang memilih nomor itulah yang menentukan dari mana pemecahan masalah dimulai.

Di klien semuanya tampak sama: satu alamat IPv4, satu masker, kadang gateway default. Perbedaannya baru muncul saat Anda bertanya siapa yang menjawab alamat itu dan siapa yang menyimpan catatannya.

Baca alamat terowongan dari sisi klien

Windows memperlihatkan perbedaannya jika Anda membaca seluruh blok, bukan baris pertama. ipconfig /all mencetak deskripsi adaptor, alamat fisik, dan baris DHCP. Adaptor dial-up PPP atau IKEv2 biasanya melaporkan DHCP nonaktif, karena koneksi menegosiasikan alamatnya saat dial-up alih-alih menyewanya dari server LAN. Adaptor terowongan dengan DHCP aktif tidak lazim dan layak diselidiki sendiri.

Linux membagi informasi yang sama ke dua alat. ip -4 addr show dev tun0 memberikan alamat dan panjang prefiks. nmcli -f IP4 connection show work mengungkap apakah nilainya berasal dari profil koneksi, pertukaran DHCP di tautan, atau konfigurasi yang didorong. WireGuard adalah kasus paling jelas, karena wg-quick menerapkan baris Address dari berkas konfigurasi saat antarmuka muncul dan tidak ada peer yang mengalokasikan apa pun saat terhubung.

Prefiks juga memberi petunjuk. /32, atau masker 255.255.255.255, berarti gateway mengharapkan perutean ke satu alamat host, sedangkan masker yang lebih lebar menandakan subnet di tautan di suatu tempat di belakang terowongan.

Apa yang dibawa muatan konfigurasi IKEv2

IKEv2 punya mekanisme khusus untuk tugas ini. Muatan konfigurasi yang dijelaskan dalam RFC 7296, bagian 3.15.1 membawa atribut seperti INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS dan padanan IPv6-nya. Klien mengirim atribut bernilai panjang nol bila tidak punya preferensi, dan penjawab mengembalikan nilai yang ingin dipakai. Pertukaran itu berjalan di dalam IKE_AUTH, sudah terenkripsi, sehingga tidak ada siaran DHCP yang melintasi terowongan.

Ada dua konsekuensinya. Pertama, alamat dipilih oleh penjawab atau backend otorisasi apa pun yang dikonsultasikannya, karena itu kumpulan bisa berada di gateway, dalam balasan RADIUS, atau dalam pemetaan penyedia identitas. Kedua, atribut DNS terpisah dari atribut alamat. Menerima 10.80.0.14 tidak mengatakan apa pun tentang resolver mana yang kembali, atau apakah ada yang kembali.

Atribut masker jaringan dalam praktik bersifat opsional. Banyak penerapan hanya mengembalikan alamat dan membiarkan klien memasang rute host, karena itu kumpulan yang sama bisa tampak seperti /32 di satu klien dan /24 di klien lain.

Tempat cakupan DHCP LAN dan kumpulan VPN bertabrakan

Masalah dimulai ketika kedua pemberi menunjuk rentang yang sama. Server DHCP untuk 10.20.30.0/24 tidak tahu apa pun tentang kumpulan VPN yang dikonfigurasi untuk 10.20.30.128/25, jadi tidak ada yang menghalanginya menyewakan 10.20.30.140 ke printer sementara gateway memberikan alamat yang sama ke klien jarak jauh. Tabrakan itu tetap senyap berhari-hari lalu muncul sebagai duplikat sesekali.

Desain situs-ke-situs yang dirutekan menghindari tabrakan secara konstruktif. Host di cabang menyimpan alamat yang diberikan server DHCP lokalnya. Antarmuka terowongan di kedua gateway membawa alamat tautannya sendiri, dan tabel perutean menentukan bagaimana paket berjalan. Alamat klien akses jarak jauh adalah kategori ketiga dan tidak boleh dicampur dengan alamat tautan gateway.

Menjembatani terowongan ke LAN menghapus pemisahan itu. Jika desainnya benar-benar memerlukan satu domain siaran, titik akhir VPN harus ikut serta dalam keputusan alokasi yang sama dengan server DHCP, melalui relai atau sumber otoritatif bersama, alih-alih menerbitkan alamat sendiri.

Verifikasi proses mana yang memiliki alamat

Buktikan kepemilikannya sebelum mengubah cakupan. Di klien, catat alamat dan prefiks. Di LAN, telusuri basis data sewa. Di gateway, daftarkan kumpulan yang dikonfigurasi untuk dibagikannya. Alamat yang ditemukan di berkas sewa milik server DHCP, yang berarti terowongan dijembatani atau direlai; alamat yang hanya ditemukan di kumpulan gateway milik titik akhir terowongan.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Catat empat hal setelah jawabannya jelas: komponen mana yang memberikan alamat klien, rentang mana yang dicadangkan untuknya, bagaimana lalu lintas balik mencapai rentang itu, dan sumber daya mana yang menerimanya. Keempat entri itu mengubah satu baris adaptor virtual menjadi fakta operasional.

Ulangi pemeriksaan atribut DNS selagi Anda di sana. Kumpulan yang membagikan alamat tanpa resolver membiarkan klien pada DNS lokalnya, yang merupakan kegagalan berbeda dari kumpulan yang membagikan alamat yang sudah dipakai LAN.