Mengapa subnet di belakang klien OpenVPN tidak dapat dijangkau?

Ping ke alamat tunnel server berhasil, tabel rute klien sendiri terlihat benar, dan LAN di belakang klien itu tetap tidak dapat dijangkau. Tabel perutean klien terlihat benar, server memiliki rute yang menunjuk ke tunnel, dan paket tetap hilang. Ini gejala klasik tunnel layer-3 yang tidak tahu bahwa salah satu kliennya juga merupakan gateway.

Antarmuka tun tidak memiliki hop berikutnya per klien. Kernel melihat satu antarmuka dengan banyak peer, jadi keputusan tentang klien mana yang harus menerima paket untuk LAN jarak jauh harus dibuat di dalam proses OpenVPN. Keputusan itu dikonfigurasi dengan iroute, dan tanpanya paket tidak punya tujuan.

Server merutekan berdasarkan klien, bukan antarmuka

Saat server perlu mengirim paket ke alamat tunnel klien, jawabannya tidak ambigu: alamat itu milik sesi klien tersebut. Saat tujuannya seluruh subnet di belakang klien itu, alamat itu bukan milik siapa pun yang dikenal server, dan rute kernel ke tunnel hanya mengatakan "lewat antarmuka ini", tanpa menyebut peer mana.

OpenVPN menyelesaikannya dengan tabel perutean internal yang memetakan prefiks tujuan ke klien tertentu. Tabel itu dibangun dari entri iroute, itulah sebabnya rute biasa di host server tidak cukup. Rute kernel membawa paket ke antarmuka tunnel; pemetaan internal memutuskan sesi mana yang menerimanya. Itulah juga sebabnya perbaikan tidak pernah muncul di keluaran rute kernel.

Jika pemetaan tidak ada, paket tiba di server, cocok dengan rute tunnel, dan dibuang karena tidak ada klien yang mengklaim tujuan. Tidak ada yang mencatat kesalahan bersih, itulah sebabnya kegagalan tampak seperti lubang hitam senyap alih-alih loop perutean.

Menulis entri iroute yang menamai klien

iroute berada di file konfigurasi khusus klien, bukan di konfigurasi utama server. Arahkan server ke direktori dengan opsi client-config-dir, lalu buat file yang namanya adalah nama umum sertifikat klien dan letakkan prefiks di dalamnya.

Untuk cabang yang LAN-nya 10.20.0.0/24 dan nama umum sertifikatnya branch-router, file di jalur itu berisi baris seperti iroute 10.20.0.0 255.255.255.0. Konfigurasi utama hanya membutuhkan opsi direktori; prefiks itu tinggal di klien.

Nama umum adalah bagian yang rapuh. Sertifikat yang diterbitkan dengan subject berbeda, atau penerapan yang mengautentikasi pengguna dengan nama pengguna sementara file dinamai menurut sertifikat, menghasilkan file yang tidak pernah dibaca. Periksa nama yang benar-benar dilaporkan server untuk sesi, dan pertimbangkan opsi yang membuat klien tidak cocok gagal alih-alih terhubung diam-diam tanpa rutenya. Mengganti nama file agar cocok dengan sertifikat adalah perbaikan lima menit yang mencegah malam yang sangat panjang.

Satu klien dapat memiliki beberapa prefiks. Tambahkan satu baris iroute per jaringan, dan simpan daftar di samping sisa pengaturan klien itu agar pemetaan tetap dapat diaudit.

Membangun jalur balik di kedua arah

Membawa paket ke LAN jarak jauh adalah separuh pekerjaan. Klien juga harus mengirim lalu lintas LAN itu ke tunnel, yang biasanya dilakukan dengan mendorong rute ke klien: baris seperti push "route 10.8.0.0 255.255.255.0" memberi tahu setiap klien cara mencapai jaringan di sisi server. Untuk cabang, rute yang setara menunjuk ke tunnel untuk apa pun yang harus dijangkau di sisi server.

Arah balik membutuhkan pemilik di sisi jauh. Di sisi itu, seseorang harus tahu jalan kembali: rute statis di router LAN yang mengarahkan kumpulan VPN ke server, atau terjemahan alamat di server sebelum lalu lintas masuk ke LAN. Rute statis menjaga alamat asli tetap terlihat di log dan aturan akses tetapi membutuhkan kerja sama pemilik LAN; terjemahan mandiri tetapi menyembunyikan siapa yang benar-benar terhubung.

Penerusan harus diaktifkan di host server. Tanpanya kernel menerima paket dari tunnel dan menolak meneruskannya ke antarmuka LAN, yang dari sudut pandang klien terlihat identik dengan iroute yang hilang.

Memeriksa keterjangkauan dengan probe yang tepat

Uji berlapis alih-alih melakukan ping ke ujung jauh dan menebak. Dari server, periksa bahwa pemetaan internal untuk prefiks ada dan rute kernel menunjuk ke tunnel. Dari klien, pastikan rute yang didorong terpasang dan jalur defaultnya untuk alamat LAN adalah tunnel.

Lalu amati paket. Tangkapan di antarmuka tunnel menunjukkan apakah server mengirim ke arah klien, dan tangkapan di antarmuka LAN menunjukkan apakah ia meneruskan. Jika yang pertama menunjukkan paket dan yang kedua tidak, masalahnya ada pada penerusan atau filter; jika keduanya tidak menunjukkan apa pun, pencarian gagal lebih awal.

Dua server yang dihubungkan tunnel mengulangi aturan yang sama di kedua sisi: masing-masing membutuhkan iroute untuk kumpulan yang lain, dan masing-masing membutuhkan rute serta penerusan yang membuat jalur simetris. Perutean dan kebijakan adalah hal terpisah di sini. Perutean memutuskan ke mana paket dapat pergi, sedangkan aturan FORWARD memutuskan apakah boleh, jadi klien dengan dua baris iroute dapat mencapai kedua prefiks kecuali filter mengatakan sebaliknya.