Di mana rute seharusnya berada di OpenVPN: di klien atau di server?
Rute telanjang dalam konfigurasi server mengubah server, bukan klien. Pilih berkas klien, push global, atau push untuk satu klien, lalu periksa apa yang tiba.
Anda menambahkan route 10.60.0.0 255.255.255.0 ke konfigurasi server, memulai ulang, menyambungkan ulang laptop, dan subnet tetap tidak dapat dijangkau dari laptop itu. Baris itu diterima, layanan dimulai dengan bersih, dan tidak ada yang tampak salah di log. Yang terjadi adalah rute dipasang di mesin yang Anda edit: gateway kini mengira dapat menjangkau prefiks itu, sementara klien tidak diberi tahu apa pun. Penempatan adalah seluruh pertanyaannya, dan ada empat tempat baris yang sama dapat hidup.
Empat tempat dan siapa yang menerima masing-masing
Rute dapat ditambahkan oleh konfigurasi klien itu sendiri, ditawarkan ke setiap klien melalui push global, ditawarkan ke satu klien melalui berkas khusus klien, atau ditulis ke dalam konteks perutean server itu sendiri.
Keempat kasus itu memakai sintaksis yang hampir sama dan menghasilkan hasil yang sangat berbeda. Tiga yang pertama memengaruhi apa yang dikirim klien ke terowongan; yang keempat memengaruhi bagaimana server menjangkau jaringan, yang berguna ketika server sendiri membutuhkan jalur dan berbahaya ketika disalahartikan sebagai distribusi.
Putuskan mana dari keempat yang Anda inginkan sebelum menulis baris, lalu pastikan penerimanya.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Mengapa rute server telanjang mengejutkan orang
Konfigurasi server adalah tempat pertama yang dilihat administrator, dan direktif rute di sana terbaca seperti pernyataan tentang jaringan VPN. Bukan. OpenVPN memperlakukannya sebagai pemasangan rute lokal di mesin yang menjalankan daemon, yang persis jenis perubahan yang akan Anda lakukan dengan ip route lalu lupakan.
Distribusi mengharuskan rute di-push, dan push mengharuskan klien menariknya. Klien yang dijalankan dengan opsi tarikan dimatikan mengabaikan tawaran itu sepenuhnya. Periksa kedua ujung jabat tangan itu sebelum menulis ulang berkas server, karena log server tidak akan mengeluh: dari sisinya tawaran sudah dikirim. Rute yang diterima juga baru berlaku pada koneksi berikutnya, tidak pernah pada sesi yang sedang Anda jalani.
Setelah Anda melihat keduanya sebagai operasi terpisah, kegagalan berhenti menjadi misterius: server menjangkau prefiks, klien tidak, dan kedua pernyataan itu benar pada saat yang sama.
Berkas per klien dan identitas yang dicocokinya
Berkas khusus klien dinamai menurut identitas yang diautentikasi server, yang secara bawaan adalah nama umum sertifikat. Nama koneksi yang ramah di klien desktop bukan nilai itu, dan ketidakcocokan menghasilkan berkas yang tidak pernah dibaca.
Periksa direktori yang benar-benar dipakai server, lalu pastikan nama berkas cocok persis dengan identitas yang diautentikasi, termasuk huruf besar dan kecil.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Di dalam berkas itu rute tetap harus di-push, karena konteks per klien adalah sekumpulan opsi yang diterapkan pada sesi klien itu, bukan tabel perutean lokal. Rute telanjang di sana punya masalah yang sama dengan rute telanjang di berkas global.
Berkas milik klien dan alat yang memilikinya
Rute yang ditempatkan di konfigurasi klien dipasang saat klien itu tersambung dan dihapus saat terputus, yang merupakan siklus hidup tepat untuk tujuan statis.
Jika pengelola jaringan memiliki profilnya, ia mungkin mengimpor opsi itu sekali lalu menyimpan salinannya sendiri. Mengedit berkas yang diunduh setelahnya tidak mengubah apa pun, yang merupakan penyebab umum "rutenya ada tetapi tidak berlaku".
Periksa profil yang aktif, bukan berkas yang Anda unduh, dan periksa pengaturan impor yang ditampilkan pengelola. Lalu sambungkan dan tanyakan kepada sistem jalur mana yang dipakai alamat tertentu, alih-alih mengasumsikan terowongan menang karena rute ada di berkas teks.
Verifikasi di klien, lalu periksa jalur kembali
Tanyakan tabel perutean milik klien tentang tujuannya, bukan tabel server. Pencarian untuk satu host di dalam prefiks sudah cukup untuk menunjukkan antarmuka dan hop berikutnya yang akan dipakai.
ip route get 10.60.0.10Jika pencarian menunjuk ke terowongan, distribusi berhasil dan masalah yang tersisa ada di tempat lain. Jika menunjuk ke gateway bawaan, rute tidak dipasang, tersaring oleh opsi di sisi klien, atau milik profil yang tidak dipakai klien.
Anggaplah distribusi berhasil dan tetap tidak ada yang merespons: maka periksa penerusan di gateway, rute kembali di sisi seberang, dan firewall apa pun di antaranya. Rute memilih jalur, ia tidak memberi akses.