OpenVPN iroute versus rute kernel: mana yang hilang?

Paket untuk 10.77.20.0/24 mengambil dua keputusan terpisah di server OpenVPN: sistem operasi harus menyerahkannya ke antarmuka VPN, dan OpenVPN harus tahu klien terhubung mana yang memiliki prefiks itu. Rute kernel yang hilang menjatuhkannya sebelum terowongan, rute peer yang hilang menjatuhkannya sesudahnya. Kedua kegagalan tampak sama dari LAN jauh, dan mendiagnosis mana yang Anda hadapi memerlukan satu perintah di tiap sisi.

Pada jalur data ruang pengguna klasik, rute kernel membawa paket ke proses terowongan dan iroute memberi tahu proses itu peer mana yang harus menerimanya. Tak satu pun menggantikan yang lain, dan konfigurasi yang hanya memuat salah satunya akan tampak wajar sampai ping pertama.

Dua keputusan, bukan satu rute

Bayangkan tautan situs-ke-situs di mana 10.77.20.0/24 berada di belakang satu klien. Rute kernel server, misalnya ip route add 10.77.20.0/24 dev tun0, mengirim paket yang cocok ke perangkat terowongan. OpenVPN lalu memeriksa tabel internalnya sendiri, yang dibangun dari entri iroute di direktori konfigurasi klien, untuk memutuskan koneksi peer mana yang menerimanya. Tanpa rute kernel paket tidak pernah mencapai proses, dan tanpa rute peer paket mencapai proses dan tidak pergi ke mana pun.

Pemisahan itu mudah dilupakan, karena satu baris rute di profil klien bisa tampak melakukan kedua tugas. Tidak: mendorong rute memberi tahu klien apa yang harus dikirim melalui terowongan, sedangkan iroute memberi tahu server siapa yang memiliki rentang alamat di belakang klien. Keduanya hidup di berkas berbeda, dibaca oleh sisi berbeda, dan gagal ke arah berlawanan.

Di mana iroute berada dan apa yang dikatakannya

Entri itu masuk ke berkas per klien yang dinamai menurut common_name klien, di bawah client-config-dir, sebagai iroute 10.77.20.0/24. Kecocokan nama berkas bukan kosmetik: OpenVPN mencari identitas yang terautentikasi dan membaca berkas dengan nama itu persis, sehingga berkas bernama site-a hanya berlaku untuk klien yang nama umumnya site-a. Tambahkan ccd-exclusive jika klien tanpa berkas semacam itu harus ditolak sepenuhnya, yang merupakan setelan tepat ketika setiap klien adalah gerbang situs. Pertahankan satu berkas per gerbang dan namai menurut subjek sertifikat yang benar-benar Anda terbitkan.

Uji entri itu dari server sebelum menyalahkan LAN jauh. Berkas status mencantumkan klien terhubung dengan nama umumnya, dan server yang berjalan dengan --verb 4 mencatat pemasangan iroute saat peer terhubung. Jika tidak ada yang muncul saat koneksi, berkas berada di direktori yang salah atau menyebut identitas yang salah.

Jebakan: berkas ada, identitas salah

iroute yang tampak benar tetapi terpasang pada peer yang salah menghabiskan lebih banyak waktu daripada berkas yang hilang, karena semua di disk tampak benar. Penggantian nama sertifikat, nama umum duplikat, dan username-as-common-name yang mengubah identitas efektif semuanya menghasilkannya. Periksa identitas mana yang diautentikasi server, bukan yang Anda harapkan: keluaran status adalah acuan, sedangkan nama berkas hanyalah kunci pencarian.

Rute bisa hidup lebih lama daripada pemiliknya. Rute statis dan entri iroute menjelaskan prefiks, bukan jaminan ketersediaan, sehingga lalu lintas dapat terus dirutekan ke peer yang saat ini terputus.

Selesaikan jalur di luar peer

Kepemilikan peer adalah bagian tengah jalur, bukan ujungnya. Klien harus meneruskan paket dari terowongan ke LAN-nya, yang berarti penerusan IP aktif di host itu dan aturan firewall mengizinkan lintasan. Host di LAN jauh memerlukan jalur balik untuk alamat terowongan: entah rute yang menunjuk kembali ke gerbang, atau desain NAT yang disengaja di sisi klien. Pastikan setelan penerusan pada klien dengan sysctl net.ipv4.ip_forward alih-alih menganggap nilai bawaan distribusi.

Jika klien VPN lain harus mencapai subnet itu, tata letaknya bertambah lagi: server memerlukan client-to-client, dan klien itu harus merutekan prefiks melalui terowongan. Tidak satu pun dari itu tersirat oleh tabel rute server sendiri.

Verifikasi satu tujuan dari sumber nyata alih-alih dari server itu sendiri. Ping dari host LAN yang tidak terkait ke host di belakang klien melatih jalur balik, aturan penerusan, dan kepemilikan peer dalam satu gerakan, sedangkan handshake yang berhasil hanya membuktikan identitas. Lalu putuskan peer pemilik dan catat apa yang dilakukan rute, karena jawaban itu adalah mode kegagalan Anda.