Router LAN dan klien VPN: dua perangkat, dua tabel rute

Dua perangkat meneruskan paket dan masing-masing menyimpan tabelnya sendiri. Router LAN tahu bahwa prefiks jarak jauh milik klien VPN, dan klien VPN tahu cara mencapai prefiks itu melalui terowongannya. Konfigurasikan hanya tabel pertama dan paket tiba di mesin yang tidak punya rute yang cocok, sehingga keluar lagi lewat rute default. Itulah seluruh kegagalannya, dan dari sisi LAN tampak seperti loop routing, karena hampir memang begitu.

Gambarlah kedua hop sebelum menyentuh rute

Ambil tata letak ilustratif: host LAN di 192.168.50.0/24, router biasa di 192.168.50.1, klien khusus di 192.168.50.15, dan LAN jarak jauh di 10.60.0.0/24 yang hanya bisa dijangkau lewat terowongan yang dipegang klien itu. Tidak ada dari kedua rentang privat yang bertumpang tindih dengan yang lain, dan terowongan itu punya rencana alamatnya sendiri.

Kedua rentang privat penting karena keduanya menentukan perangkat mana yang bisa menjawab. Sisi jauh akan melihat paket datang dari alamat terowongan klien, dan balasannya harus menemukan jalan kembali ke 192.168.50.0/24. Jika hanya arah keluar yang dikonfigurasi, permintaan bisa berhasil sementara balasannya menghilang.

Langkah 1: arahkan router ke klien, bukan ke terowongan

Di router LAN, tambahkan rute tujuan yang hop berikutnya adalah alamat LAN klien:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Catatan itu berkata “antar ke mesin yang bisa membuat terowongan”. Itu tidak mengatakan apa pun tentang bagaimana terowongan dibangun, dan itu bukan pengganti rute klien sendiri. Pada router terkelola, padanannya ada di halaman rute statis perangkat; pada router Linux, itu termasuk konfigurasi antarmuka yang memiliki LAN, bukan shell yang akan Anda tutup.

Periksa jawaban perintah kedua. Jika ia melaporkan klien sebagai gateway dan antarmuka LAN sebagai device, hop pertama benar dan sisa pekerjaan ada di mesin lain.

Langkah 2: beri klien rute sendiri di sisi terowongan

Klien kini menerima paket untuk 10.60.0.0/24 dan melihat tabelnya sendiri. Jika konfigurasi terowongannya memasang rute untuk prefiks itu, paket berlanjut terenkripsi. Jika tidak, paket cocok dengan default biasa dan kembali ke 192.168.50.1, yang mengirimnya lagi ke klien.

Lihatlah sebelum menambahkan apa pun:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Rute prefiks yang hilang di semua tabel adalah temuan yang Anda cari. Tambahkan melalui konfigurasi terowongan itu sendiri, agar sambungan ulang berikutnya memasangnya lagi; ip route add manual hilang bersama sesi dan membuat kesalahan kembali pada saat paling tidak nyaman. Hop berikutnya adalah antarmuka terowongan atau alamat yang ditetapkan VPN sebagai peer-nya, tergantung klien, dan alamat peer harus berasal dari profil saat ini, bukan dari catatan lama.

Loop, ketika terjadi, dalam praktiknya tidak tak terhingga: TTL turun pada setiap lintasan dan paket mati dengan pesan waktu terlampaui. Itulah sebabnya traceroute berulang bisa menyarankan siklus sementara klien yang sekadar tidak meneruskan menjatuhkan paket yang sama secara diam-diam.

Langkah 3: izinkan penerusan dan pilih jalur balik

Menerima dan meneruskan adalah izin yang berbeda. net.ipv4.ip_forward=1 pada klien mengizinkan transit di tingkat kernel, dan aturan firewall tetap harus mengizinkannya antara antarmuka LAN dan terowongan. Aturan yang mengizinkan akses ke halaman manajemen klien sendiri tidak akan mengizinkan transit ke LAN jarak jauh, dan perbedaannya mudah terlewat ketika host yang sama menjawab ping secara lokal.

Sisi jauh punya masalah cermin. Ia harus tahu bahwa 192.168.50.0/24 dapat dijangkau melalui klien yang terautentikasi ini. Dengan OpenVPN itu biasanya berarti rute per klien yang didorong oleh konfigurasi server, atau berkas khusus klien di server yang mendeklarasikan LAN di belakang klien. Tanpa itu, LAN jarak jauh entah menjatuhkan balasan atau mengirimnya ke gateway default-nya sendiri, yaitu internet.

Penerjemahan sumber adalah alternatifnya ketika prefiks LAN tidak dapat diumumkan. Aturan masquerade yang tercakup pada klien menulis ulang sumber ke alamat terowongan, dan balasan kemudian kembali secara alami. Ini juga menyembunyikan host LAN mana yang membuat permintaan, dan dengan sendirinya tidak mengizinkan sisi jauh memulai koneksi ke dalam. Pilih kompromi itu dengan sengaja alih-alih menambahkan masquerade menyeluruh dan menemukan efek sampingnya nanti.

Langkah 4: buat kedua keputusan tetap, lalu uji jalur sebenarnya

Setiap rute punya pemilik, dan pemiliknya adalah konfigurasi yang dibuat ulang saat boot atau saat sambung ulang. Di router itu bisa berupa entri rute statis; di klien bisa berupa profil VPN, NetworkManager, atau systemd-networkd. Verifikasi dengan menyambung ulang terowongan dan menyalakan ulang klien, lalu baca tabelnya lagi alih-alih memercayai suntingan.

Jaga utuh rute default yang membawa koneksi luar terowongan. Menggantinya untuk “menyederhanakan” penyiapan merusak jalur terenkripsi sebelum lalu lintas dalam apa pun bisa memakainya, dan gejalanya adalah terowongan yang tidak pernah terbentuk lagi setelah perubahan.

Uji dari host LAN biasa, bukan dari klien, karena permintaan yang berasal dari klien tidak pernah menjalankan hop pertama router. Ambil layanan yang hanya ada di LAN jarak jauh dan pastikan isi balasannya, lalu periksa penghitung atau log klien untuk melihat transit terjadi. traceroute dalam yang menunjukkan hop privat membuktikan penerusan, bukan enkripsi: jalur luar adalah pengamatan terpisah, dan hanya penghitung antarmuka terowongan itu sendiri yang menunjukkan apa yang keluar melaluinya.