OpenVPN terus mendorong rute lama? Periksa apa yang dimuatnya

Anda menambahkan rute, memulai ulang layanan, menyambung ulang, dan tabel klien tampak persis seperti sebelumnya. Dua hal berbeda bisa benar: server tidak pernah memuat perubahan Anda, atau klien tidak pernah memasang apa yang diterimanya. Keduanya tidak punya kesamaan selain gejalanya, jadi langkah pertama adalah mencari tahu mana yang Anda hadapi.

Perbandingan di bawah bergerak dari proses ke luar, karena proses adalah satu-satunya otoritas tentang berkas mana yang berlaku.

Berkas yang Anda sunting dan berkas yang dibaca proses

Mulai dari unit dan baris perintah yang dihasilkannya. Pada host systemd, systemctl cat openvpn@server mencetak baris ExecStart, dan unit instance biasanya menurunkan jalur konfigurasinya dari nama instance, sehingga daemon yang dijalankan sebagai openvpn@office membaca berkas berbeda dari yang dijalankan sebagai openvpn@server. Bandingkan itu dengan argv proses yang berjalan. Alat manajemen konfigurasi menambah cara lain kehilangan perubahan: ia bisa menulis berkas yang benar ke lokasi yang tidak pernah disebut unit, sehingga penerapan yang hijau tampak tidak berbuat apa-apa.

Stempel waktu menyelesaikannya dengan cepat: jika berkas lebih baru daripada waktu mulai proses, proses tidak mungkin membacanya. Firmware router menambah kasus ketiga, karena banyak model menyimpan pengaturannya di flash dan membangun ulang konfigurasi saat boot, yang membuat penyuntingan berkas di disk berada di lapisan yang sama sekali salah.

Apa yang didorong server dan apa yang dipasang klien

Rute yang didorong harus lolos dua penyaring. Di server rute itu harus berada dalam konfigurasi yang dimuat, bukan di blok yang dikomentari atau di berkas khusus klien yang namanya tidak cocok. Di klien, pull harus aktif dan tidak ada pull-filter yang membuang opsi itu. Sambungkan dengan verbosity 4 dan baca opsi yang didorong yang dilaporkan klien: jika rute muncul di daftar itu, server sudah melakukan tugasnya dan klien yang memilih untuk tidak memasangnya.

Berkas khusus klien sering menjadi sumber kebingungan. Berkas yang dinamai menurut common name sertifikat hanya mendorong opsi ke klien itu, dan selisih satu karakter menghentikan dorongan secara diam-diam, tanpa galat di kedua sisi. Server mencatat common name yang dilihatnya saat koneksi, jadi bandingkan nilai itu dengan nama berkas, bukan dengan apa yang Anda kira sebagai nama klien.

Prefiks yang didorong dan rute balik adalah masalah yang berbeda

Klien yang sengaja mengabaikan redirect-gateway untuk mempertahankan jalur internet lokalnya menciptakan celah kedua yang tidak berkaitan. Probe server mencapai alamat tunnel dan jawabannya tidak pernah tiba, karena balasan yang dialamatkan ke IP tunnel server dirutekan melalui gateway default biasa klien. Rute subnet yang didorong tidak bersalah di sini; yang tidak ada adalah rute yang mengirim lalu lintas jaringan tunnel server kembali melalui perangkat tunnel.

Menambahkan rute itu di klien memperbaiki jawaban atas probe yang dimulai server. Rute itu bukan pengganti rute subnet yang didorong, dan sebaliknya juga benar, karena keduanya menggambarkan arah perjalanan yang berlawanan.

Bandingkan tabel di kedua ujung

Setelah perubahan apa pun, sambungkan ulang dan baca tabel klien untuk prefiks yang didorong dan untuk perangkat tunnel. Lalu uji kedua arah: dari klien ke host di subnet yang didorong, dan dari host itu kembali ke klien. Rute yang ada tetapi tidak membawa lalu lintas berarti salah satu dari tiga hal: sisi jauh tidak meneruskan, firewall menjatuhkan aliran, atau jawaban tidak punya jalan kembali.

Simpan tiga pengenal bersama: jalur konfigurasi, nama unit atau instance, dan identitas klien yang Anda gunakan untuk menguji.

Ketiganya menjadikan kejadian berikutnya pemeriksaan lima menit alih-alih penyelidikan ulang, dan itulah yang dibutuhkan rekan kerja ketika tunnel menjadi masalah orang lain.

Masalah rute yang bertahan setelah mulai ulang sering bukan masalah perutean sama sekali; kesalahannya berada di hulu tabel yang terus Anda baca.