Pesan "File exists" OpenVPN pada rute bukan masalah berkas

Mulailah dari tempat pesan muncul. Sebuah klien terhubung, terowongan naik, lalu log melaporkan bahwa perintah menambah rute Linux gagal dengan File exists. Tidak ada yang dalam kalimat itu merujuk pada sertifikat, kunci, atau berkas konfigurasi, meskipun kata-katanya menyarankan demikian. Kernel sedang menjelaskan tabel rutnya, dan prefiks yang Anda minta dipasang sudah memiliki entri.

Ikuti urutan klien itu sendiri: apa yang dimintanya, apa yang sudah ada di tabel, siapa yang menaruh entri itu di sana, dan baru kemudian apa yang harus diubah. Setiap langkah menghapus satu kemungkinan pemilik.

Apa yang sebenarnya diminta klien

Sebelum kegagalan, klien mencatat rute yang hendak ditambahkannya, biasanya sebagai tujuan, mask jaringan, gateway, dan kadang sebagai metrik atau tabel. Baris itulah permintaannya. Galat berikutnya adalah jawaban kernel, dan keduanya harus dibaca berdampingan.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Status keluar bukan nol dari pembantu rute kurang informatif daripada teks di bawahnya, karena berbagai respons kernel menghasilkan status bukan nol. Simpan pesan persisnya; perbedaan antara entri yang sudah ada dan gateway yang tak terjangkau menentukan bagian mana berikutnya yang berlaku.

Baca rute yang ada, bukan hanya alamatnya

Mencari di tabel empat serangkai bertitik yang sama tidak cukup. Objek rute diidentifikasi oleh keluarga alamat, tabel, prefiks tujuan, metrik, protokol, dan perangkat keluaran, dan entri yang berbagi prefiks dapat hidup berdampingan secara sah ketika atribut itu berbeda. Yang bertabrakan adalah seluruh objeknya, bukan teksnya.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Perintah terakhir menjawab pertanyaan berbeda dari dua yang pertama: bukan apa yang ada, melainkan entri mana yang akan dipilih kernel untuk tujuan itu saat ini. Kedua pandangan berguna, dan keduanya cukup sering berbeda sehingga layak dibandingkan sebelum menyimpulkan apa pun. Ketidakcocokan di antara keduanya adalah kasus yang menarik, bukan galat pembulatan.

Catat prefiks, tabel, metrik, dan perangkat di samping permintaan yang gagal. Jika entri yang ada memiliki atribut yang sama dan lompatan berikutnya yang sama, Anda memiliki instruksi ganda, bukan masalah perutean.

Empat pemilik yang bisa dimiliki sebuah prefiks

Rute terhubung berasal dari alamat yang ditetapkan dan dibuat ulang oleh sistem setiap kali alamat itu ada. Klien DHCP atau manajer koneksi memasang rute sebagai bagian dari siklus hidupnya sendiri. Klien VPN lain mungkin sudah membawa prefiks yang sama. Dan hook atau skrip lokal dapat menambahkan satu yang tidak diketahui apa pun.

Setiap pemilik memerlukan koreksi berbeda. Rute terhubung bukan milik Anda untuk dihapus; menghapusnya dapat memutus akses lokal sebelum terowongan dapat digunakan, dan kernel akan mengembalikannya. Rute milik manajer harus diubah melalui manajer itu, bukan dengan ip route del manual yang dibatalkan oleh penyambungan ulang berikutnya.

Antarmuka yang dipertahankan membuat kebingungan yang sama lebih mudah. Ketika perangkat terowongan bertahan dari penyambungan ulang, rute yang dipasang oleh kode penyiapan khusus mungkin masih ada pada proses kedua, sehingga skrip yang mengasumsikan keadaan bersih gagal pada kedua kalinya dan berhasil pada pertama. Entah bersihkan entri basi dengan sengaja atau buat kode penyiapan idempoten.

block-local menjawab pertanyaan lain

Ketika profil mengirim semua lalu lintas melalui terowongan, klien harus memutuskan apa yang terjadi dengan jaringan lokal. Tanda block-local mengubah keputusan itu dengan merutekan LAN lokal melalui terowongan sambil mempertahankan pengecualian terdokumentasi untuk gateway LAN; ini pilihan kebijakan lalu lintas dengan konsekuensi nyata bagi keterjangkauan.

Ini tidak menjelaskan mengapa penambahan rute mengembalikan galat entri yang sudah ada, dan mengadopsinya sebagai perbaikan universal menyembunyikan konflik sebenarnya di balik perubahan kebijakan. Jika sumber daya lokal Anda menjadi tak terjangkau setelah pengeditan profil, tanda ini salah satu hal pertama yang perlu diperiksa; jika penambahan rute gagal, ini bukan jawabannya.

Perlakukan ini sebagai keputusan tentang tujuan mana yang tetap lokal, yang diambil dengan sengaja dan dicatat. Ini bukan sakelar untuk dicoba ketika log tampak mengkhawatirkan.

Tutup lingkarannya: hapus duplikat di sumbernya

Setelah Anda tahu pemilik mana yang memegang entri, hapus instruksi ganda di tempat instruksi itu didefinisikan. Itu bisa berupa baris route di profil, push dari server, atau hook yang tidak perlu dijalankan lagi.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Lalu sambungkan ulang dan pastikan tiga hal: terowongan naik, tujuan yang dimaksud terurai ke jalur yang Anda inginkan, dan kegagalan hilang tanpa yang baru muncul menggantikannya. Log bersih dengan jalur yang salah dipilih bukan perbaikan.

Jika prefiks berarti LAN lokal di satu sisi dan jaringan jarak jauh di sisi lain, masalahnya adalah tumpang tindih alamat, bukan duplikat, dan tidak ada penghapusan yang membuat kedua makna benar sekaligus. Kasus itu memerlukan rencana berbeda untuk salah satu dari dua jaringan. Putuskan sisi mana yang akan dinomori ulang sebelum Anda menyentuh salah satunya.