Klien VPN jarak jauh terhubung, server LAN menjawab, dan balasannya keluar lewat router internet biasa lalu mati di sana. Satu server bisa diperbaiki dengan rute statis, tetapi satu subnet penuh lebih baik ditangani di tempat mereka sudah mendapatkan konfigurasi jaringannya. Opsi 121 DHCPv4 mendistribusikan persis rute tujuan semacam itu, dan itulah bagian yang biasanya salah dilakukan orang begitu mereka lupa rute default. Gejalanya adalah lalu lintas satu arah: permintaan datang dan balasan menghilang.

Sebutkan dulu ketiga alamatnya

Ambil LAN konkret: 192.168.50.0/24 dengan router default biasa di 192.168.50.1 dan gateway VPN terpisah di 192.168.50.2. Klien jarak jauh yang terautentikasi menempati 10.90.0.0/24.

Rute yang dibutuhkan setiap host peserta adalah 10.90.0.0/24 via 192.168.50.2. Tujuannya adalah kumpulan klien, dan hop berikutnya adalah alamat LAN gateway, bukan alamat tunnelnya.

Enkodekan sebagai rute statis tanpa kelas

Opsi 121 membawa pasangan prefiks dan hop berikutnya, dan RFC 3442 mendefinisikan baik pengodean maupun perilaku klien yang mengikutinya. Untuk instans dnsmasq yang sudah ada dan hanya melayani LAN ilustratif ini, bentuk konfigurasinya adalah:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Itu sebuah fragmen, bukan layanan DHCP baru. Pada server yang menangani beberapa segmen, batasi opsi dengan tag atau kebijakan jaringan yang sudah Anda pakai. Simpan konfigurasi sebelumnya, karena mengembalikannya berarti satu pembaruan sewa lagi, bukan reboot.

Jangan kehilangan rute default

Inilah jebakannya. Klien yang menerima opsi 121 harus mengabaikan opsi Router biasa, jadi mengumumkan hanya rute kumpulan VPN bisa membuat host itu sama sekali tanpa rute default. Mesinnya masih tampak terkonfigurasi dan diam-diam kehilangan internet. Pengguna menggambarkannya sebagai jaringan mati padahal semua antarmuka hidup.

Sertakan default yang dimaksud dalam daftar yang sama, seperti yang dilakukan fragmen di atas. Pertahankan juga opsi Router biasa, untuk klien yang tidak menerapkan rute tanpa kelas; penanganan opsi milik server sendiri yang menentukan apa dikirim ke siapa.

Periksa apa yang akan diterima klien

Host dengan alamat manual tidak pernah menangkap ini, karena tidak meminta sewa. Dukungan klien juga berbeda-beda, jadi ujilah pada sistem operasi yang benar-benar Anda jalankan alih-alih menganggap setiap perangkat menghormati opsi 121. Pastikan dengan pemilik server tersebut mana yang beralamat statis. Host itu perlu entri rute sendiri atau mereka tidak akan berpartisipasi.

Layanan DHCP terkelola adalah batas lain. Sebagian jaringan cloud tidak mengizinkan administrator menerbitkan opsi sembarang, dan server DHCP pesaing di segmen yang sama lebih buruk daripada tidak ada opsi sama sekali.

Verifikasi sewa, lalu pencarian

Minta pemilik DHCP menerapkan perubahan, lalu perbarui sewa pada klien. Sewa yang ada mempertahankan konfigurasi lama sampai diperbarui, jadi hasil langsung tidak dijamin.

Pada klien Linux, baca rute sebenarnya dan konfirmasi kedua entri:

ip -4 route
ip -4 route get 10.90.0.23

Pencarian kontekstual seharusnya menunjukkan rute kumpulan lewat 192.168.50.2 dan default lewat 192.168.50.1. Jika default hilang, Anda telah mereproduksi jebakan di atas.

Lalu uji pertukaran sebenarnya

Distribusi rute bukan seluruh jalur. Gateway terpisah masih perlu penerusan, kepemilikan peer jarak jauh, dan kebijakan akses yang mengizinkan server, dan DHCP tidak mengautentikasi siapa pun.

Terakhir, simpan rencana penghapusan. Rute statis yang dipelajari tidak menarik dirinya sendiri saat VPN mati, jadi hop berikutnya yang usang bisa membuat prefiks itu menjadi lubang hitam jauh setelah tunnel hilang.

Artikel terkait