Impor di NetworkManager gagal pada file OpenVPN dan WireGuard

Saya memilih Impor dari berkas… di Pengaturan GNOME, memilih profil yang berfungsi dengan klien vendor, dan dialog tertutup tanpa menambahkan apa pun ke daftar. Di laptop kedua, impor selesai, koneksi muncul dengan nama profil, lalu gagal pada permintaan autentikasi pertama. NetworkManager tidak pernah menjalankan file .ovpn atau wg-quick Anda apa adanya. Ia menyerahkan file ke parser, parser mengubahnya ke format koneksi milik NetworkManager sendiri, dan sejak itu terowongan dibangun dari objek hasil parsing tersebut — rahasia, rute, DNS, dan semuanya. Jadi pertanyaan yang berguna bukanlah mengapa file rusak, melainkan apakah parsing terjadi dan apa yang dipertahankannya.

Apa yang sebenarnya dilakukan impor terhadap file

Untuk OpenVPN, parser berada di paket plugin, dan koneksi yang dibuatnya menunjuk ke layanan D-Bus seperti org.freedesktop.NetworkManager.openvpn. Tanpa plugin, tidak ada parser: tipe ini tidak dikenal nmcli, dan daftar tambah VPN grafis mungkin tidak menampilkan entri impor sama sekali. WireGuard berbeda dalam satu hal penting — NetworkManager memiliki pengaturan WireGuard sendiri sejak seri 1.30, jadi tidak ada paket plugin terpisah, tetapi pembaca wg-quick hanya ada di build yang menyertakannya.

Bagaimanapun, file dibaca satu kali. Hasilnya ditulis sebagai keyfile di bawah /etc/NetworkManager/system-connections/, dinamai menurut koneksi, dimiliki root, dan tidak dapat dibaca pengguna lain karena berisi materi kunci. Keyfile itu sekarang adalah koneksinya; menyunting file .ovpn asli setelahnya tidak mengubah apa pun.

Tiga gejala milik tiga tahap berbeda. Tidak ada entri impor atau tipe tidak dikenal berarti plugin atau versinya tidak ada. Kesalahan impor yang menyebut sebuah direktif berarti parser membaca file dan menolak sebagian isinya. Koneksi yang ada tetapi tidak pernah aktif berarti objek hasil parsing tidak lengkap atau sisi server menolaknya. Tentukan mana dari ketiga kasus yang Anda hadapi sebelum menyunting apa pun.

Pastikan plugin ada sebelum men-debug profil

Plugin yang hilang tampak persis seperti profil rusak, jadi periksa paketnya lebih dulu. Di Debian dan Ubuntu, dukungan OpenVPN tersedia sebagai network-manager-openvpn ditambah pembantu desktop; di Fedora paketnya NetworkManager-openvpn dan NetworkManager-openvpn-gnome; di Arch adalah networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Lalu impor dari jalur absolut: nmcli connection import type openvpn file /home/you/profile.ovpn. Jalur relatif biasanya berfungsi, tetapi shell yang telah berpindah direktori mengubah impor cepat menjadi jalan memutar. Untuk WireGuard, periksa nmcli --version dan pastikan sisi kernel ada dengan modprobe wireguard; impor yang berhasil di mesin tanpa modul meninggalkan Anda dengan koneksi yang perangkatnya tidak pernah muncul. Referensi nmcli mendokumentasikan subperintah import dan nama tipe yang diterima. Jika type wireguard ditolak mentah-mentah, build tersebut lebih tua dari fitur ini, dan langkah yang benar adalah paket distribusi atau backport — bukan menyalin konfigurasi ke direktori sembarang dengan harapan sesuatu membacanya.

Baca koneksi OpenVPN, bukan .ovpn

Setelah koneksi ada, baca pengaturan hasil parsing alih-alih membaca ulang file: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Anda menginginkan remote dan port, transport, materi identitas — ca, cert, key, tls-auth atau tls-crypt — dan metode autentikasi. Pada profil dengan kata sandi kunci privat, tambahkan sudo nmcli --show-secrets connection show "Work VPN" dan lihat secret flag: 0 adalah none, jadi rahasianya ada di keyfile; 1 adalah agent-owned; 2 adalah not-saved, artinya tidak pernah ditulis ke keyfile; 4 adalah not-required, artinya tidak diperlukan rahasia sama sekali. Itu bit, bukan skala, jadi 3 hanyalah agent-owned plus not-saved. Rahasia yang ditanyakan sekali per sesi adalah agent-owned (1), dengan agen yang memintanya; tidak ada nomor flag terpisah untuk itu. Ketidakcocokan flag adalah alasan biasa sebuah profil terhubung dari applet desktop dan gagal dari skrip atau saat boot.

Cara tercepat melihat apa yang dibuang parser adalah meminta plugin menulis file kembali lalu membandingkannya: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktif yang hilang dalam diff itu tidak akan ada saat koneksi. Hook adalah tersangka biasa — script-security, up, down, dan route-up mengharapkan skrip yang berjalan dengan hak tinggi dan sengaja tidak dibawa. Jangan turunkan verifikasi atau beri hak istimewa tambahan agar impor berhasil; opsi yang tidak didukung biasanya mencerminkan kumpulan fitur plugin, bukan server yang tidak terjangkau. Pindahkan perilaku itu ke skrip dispatcher NetworkManager atau ke kebijakan sisi server.

Pastikan juga kolom identitas bertahan: referensi CA, remote-cert-tls, dan pemeriksaan nama apa pun yang diandalkan profil. Koneksi yang naik tanpa itu mungkin berbicara dengan apa pun yang menjawab di alamat tersebut.

Baca koneksi WireGuard, bukan file wg-quick

File wg-quick adalah format dengan semantik shell; koneksi yang diimpor adalah sekumpulan pengaturan. PrivateKey menjadi kunci privat antarmuka, Address menjadi satu atau beberapa alamat IPv4 dan IPv6, DNS dipetakan ke properti resolver NetworkManager, MTU dipetakan ke wireguard.mtu (nilai bawaan wg-quick sendiri adalah 1420), dan setiap blok peer menjadi entri peer dengan kunci publik, endpoint, IP yang diizinkan, dan persistent keepalive. Cetak apa yang tersimpan dengan nmcli --show-secrets connection show wg0; jika daftar peer tidak muncul di keluaran itu, baca keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Yang tidak bertahan adalah separuh shell dari wg-quick. PreUp, PostUp, PreDown, PostDown, dan Table adalah perilaku alat itu, bukan atribut antarmuka WireGuard, jadi tidak ada yang menjalankannya setelah impor. Jika aslinya memakai Table = off untuk membiarkan rute bawaan, rilis NetworkManager terbaru menyediakan ip4-auto-default-route dan ip6-auto-default-route untuk tujuan yang sama; setel secara eksplisit alih-alih menganggap koneksi berperilaku seperti skrip. Hook yang mendorong rute khusus memerlukan rute itu di pengaturan perutean koneksi, kalau tidak ia akan hilang begitu saja.

Beri koneksi tepat satu pemilik

Kegagalan lanjutan yang klasik adalah koneksi yang berfungsi sampai boot berikutnya lalu berputar-putar. Biasanya [email protected] masih aktif dari percobaan sebelumnya, atau klien vendor menjalankan daemonnya sendiri, dan dua pemilik menulis rute dan DNS untuk tujuan yang sama. NetworkManager menyetel resolver lewat jalurnya sendiri, wg-quick menulis lewat resolvconf, dan penulis terakhir menang — sehingga resolusi nama berfungsi, lalu berhenti, lalu berfungsi lagi. Periksa systemctl status wg-quick@wg0, nmcli connection show --active, dan ip link show type wireguard, lalu nonaktifkan pemilik kedua alih-alih menyetel metriknya.

Jika Anda benar-benar memerlukan keduanya, beri mereka antarmuka terpisah dan IP yang diizinkan yang saling lepas, dan biarkan tepat salah satunya memasang rute bawaan. Dua rute bawaan dengan metrik berbeda bukan split tunnel; itu perlombaan yang diputuskan oleh layanan yang mulai kedua. Dan setelah menyambung ulang, periksa lagi status yang diterapkan — penyuntingan resolver manual sekali jalan yang membuat semuanya bekerja bukan bukti bahwa impor sudah lengkap.

Verifikasi dengan lalu lintas dan bertahanlah dari reboot

Naikkan koneksi dengan nmcli connection up "Work VPN", lalu baca status, alamat, dan rute alih-alih memercayai ikon: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, dan pencarian sungguhan untuk nama yang hanya terurai di dalam terowongan. Handshake atau ping yang berhasil hanya membuktikan kriptografi bekerja; itu tidak mengatakan apa pun tentang penerusan, awalan split tunnel, atau DNS privat, dan itulah bagian yang biasanya rusak.

Lalu reboot dan ulangi. Perilaku autoconnect, antarmuka yang berganti nama, dan plugin yang dimuat setelah perangkat semuanya kegagalan yang hanya Anda lihat saat boot bersih. journalctl -u NetworkManager -b --no-pager | tail -n 40 menunjukkan apa yang dilakukan daemon dengan koneksi ini pada boot ini. Untuk komputer kedua, salin keyfile dan pertahankan milik root dengan mode 600, atau gunakan nmcli connection export untuk OpenVPN dan impor ulang .ovpn yang dihasilkan — jalur ekspor tidak punya padanan WireGuard, jadi arah itu adalah salinan file atau impor baru dari aslinya yang terlindungi.

Versi singkat, berurutan: pastikan plugin atau versi NetworkManager, impor dari jalur absolut, baca pengaturan hasil parsing termasuk secret flag, bandingkan ekspor OpenVPN dengan aslinya, periksa hook dan rute di sisi WireGuard, nonaktifkan pemilik kedua mana pun, lalu setelah reboot verifikasi resolusi nama dan tabel rute. Ketika sebuah koneksi lolos semua itu, file profil yang memulainya dapat kembali ke penyimpanan terlindungi.