Rute yang didorong OpenVPN tidak terpasang: waktu, hak, atau kebijakan

Server mengatakan sudah mendorong rute, klien mengatakan sudah terhubung, tetapi tujuan tetap tidak terjangkau. Tiga penyebab menghasilkan gambaran persis seperti itu. Penambahan rute berjalan sebelum perangkat ada, klien tidak memiliki hak untuk mengubah tabel, atau kebijakan memerintahkan klien mengabaikan opsi yang didorong.

Dari luar semuanya tampak sama dan memerlukan perbaikan berbeda. Baca log klien pada titik ketika keputusan rute diambil.

Buktikan bahwa rutenya tidak ada, bukan hanya rusak

Mulailah dengan membuktikan bahwa rute tidak ada, bukan rusak. Di Linux, ip route show dev tun0 mencantumkan apa yang dipasang klien pada perangkat tunnel. Di Windows, route print atau Get-NetRoute menunjukkan hal yang sama dalam bentuk tabel.

Rute yang ada tetapi tidak meneruskan lalu lintas adalah masalah lain. Itu memindahkan penyelidikan ke aturan penerusan dan firewall, bukan ke pemasangan rute.

Waktu: penambahan berjalan sebelum perangkat ada

Klien mengurai PUSH_REPLY dari server setelah kanal kendali aktif dan setelah mengonfigurasi antarmuka. Hanya setelah itu ia menyentuh tabel perutean, dengan mekanisme apa pun yang disediakan platform. Linux melewati netlink; Windows memakai API yang membutuhkan token yang ditinggikan. Skrip atau klien yang menambahkan rute begitu membaca konfigurasi dapat berjalan sebelum perangkat TUN/TAP ada, dan kernel menolak penambahan itu.

Balapan yang sama menjelaskan mengapa rute yang diketik tangan berhasil sementara yang otomatis tidak: saat Anda mengetiknya, antarmuka sudah aktif.

route-delay ada untuk kasus ini, dan route-up menamai skrip yang berjalan setelah antarmuka dan rute dikonfigurasi. Letakkan rute yang bergantung pada alamat tunnel di kait itu, bukan pada tahap awal.

Hak: siapa yang boleh mengubah tabel

Mengubah tabel perutean Windows membutuhkan token yang ditinggikan. GUI yang dijalankan pengguna standar dapat menetapkan alamat adaptor melalui layanan dan tetap tidak bisa menambahkan rute. Log lalu menampilkan kesalahan bergaya akses ditolak, bukan dorongan yang hilang.

Menjalankan GUI sebagai administrator, atau memakai klien berbasis layanan, mengubah hasil itu. Tugas terjadwal yang menjalankan klien tanpa token yang diperlukan tidak.

Periksa akun mana yang benar-benar dipakai klien sebelum mengubah apa pun. Versi dan mode layanan menentukan penyebab mana yang mungkin, jadi catat keduanya di samping keluaran rute.

Kebijakan: rute yang didorong dapat dibuang dengan sengaja

route-nopull membuat klien mengabaikan rute yang didorong server, termasuk rute default yang didorong, sementara alamat tunnel tetap diterima. Opsi DNS dan DHCP yang didorong dibuang oleh direktif yang sama. Klien seperti itu tidak rusak; ia mengharapkan baris rute eksplisit dalam konfigurasinya sendiri.

route-noexec adalah kontrol berbeda: ia menghentikan klien sepenuhnya dari menjalankan perubahan rute. Topologi yang tidak dapat dipetakan klien dapat menghasilkan hasil serupa, dengan rute dicatat sebagai ditolak alih-alih ditambahkan. Baca baris log yang melaporkan keputusan alih-alih menebak yang mana dari ketiganya berlaku. Lalu periksa profil efektif, karena importir atau alat manajemen dapat menambahkan opsi yang tidak pernah diedit pengguna.

Profil yang tampak bersih di editor teks masih bisa membawa direktif tambahan saat runtime.

Bandingkan daftar dorong dengan tabel

Setelah terhubung, letakkan daftar dorong server di samping tabel klien. Di Linux itu ip route show dev tun0; di Windows, route print atau Get-NetRoute. Jika rute tidak ada, perbaiki pemasangan dulu. Jika ada tetapi lalu lintas gagal, lanjutkan ke kebijakan penerusan dan firewall.

Catat versi klien, akun yang dipakainya, dan apakah klien berbasis layanan. Ketiga fakta itu memberi tahu orang berikutnya penyebab mana yang telah disingkirkan.