Import dalam NetworkManager gagal pada fail OpenVPN dan WireGuard

Saya memilih Import daripada fail… dalam Tetapan GNOME, memilih profil yang berfungsi dengan klien vendor, dan dialog ditutup tanpa menambah apa-apa pada senarai. Pada komputer riba kedua, import selesai, sambungan muncul dengan nama profil, kemudian gagal pada permintaan pengesahan pertama. NetworkManager tidak pernah menjalankan fail .ovpn atau wg-quick anda sebagaimana adanya. Ia menyerahkan fail kepada penghurai, penghurai menukarnya kepada format sambungan NetworkManager sendiri, dan dari situ terowong dibina daripada objek yang dihurai itu — rahsia, laluan, DNS dan segala-galanya. Jadi soalan yang berguna bukanlah mengapa fail itu rosak, tetapi sama ada penghuraian berlaku dan apa yang dikekalkannya.

Apa yang sebenarnya dilakukan import terhadap fail

Bagi OpenVPN, penghurai terletak dalam pakej pemalam, dan sambungan yang diciptanya menunjuk kepada perkhidmatan D-Bus seperti org.freedesktop.NetworkManager.openvpn. Tiada pemalam, tiada penghurai: jenis itu tidak dikenali oleh nmcli, dan senarai tambah VPN bergrafik mungkin tidak memaparkan entri import langsung. WireGuard berbeza pada satu perkara penting — NetworkManager mempunyai tetapan WireGuard sendiri sejak siri 1.30, jadi tiada pakej pemalam berasingan, tetapi pembaca wg-quick hanya wujud dalam binaan yang menyertakannya.

Walau apa pun, fail dibaca sekali. Hasilnya ditulis sebagai keyfile di bawah /etc/NetworkManager/system-connections/, dinamakan sempena sambungan, dimiliki root dan tidak boleh dibaca oleh pengguna lain kerana ia menyimpan bahan kunci. Keyfile itu kini ialah sambungan; menyunting fail .ovpn asal selepas itu tidak mengubah apa-apa.

Tiga gejala tergolong dalam tiga peringkat berbeza. Tiada entri import atau jenis tidak dikenali bermakna pemalam atau versi tiada. Ralat import yang menamakan sesuatu direktif bermakna penghurai membaca fail itu dan menolak sebahagian daripadanya. Sambungan yang wujud tetapi tidak pernah diaktifkan bermakna objek yang dihurai tidak lengkap atau pelayan menolaknya. Tentukan yang mana antara tiga kes itu anda hadapi sebelum menyunting apa-apa.

Sahkan pemalam sebelum menyahpepijat profil

Pemalam yang hilang kelihatan sama seperti profil yang rosak, jadi semak pakej dahulu. Pada Debian dan Ubuntu sokongan OpenVPN disertakan sebagai network-manager-openvpn serta pembantu desktop; pada Fedora pakejnya NetworkManager-openvpn dan NetworkManager-openvpn-gnome; pada Arch ia networkmanager-openvpn.

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

Kemudian import dari laluan mutlak: nmcli connection import type openvpn file /home/you/profile.ovpn. Laluan relatif biasanya berfungsi, tetapi shell yang telah bertukar direktori menjadikan import pantas sebagai memutar belit. Bagi WireGuard, semak nmcli --version dan pastikan bahagian kernel wujud dengan modprobe wireguard; import yang berjaya pada mesin tanpa modul meninggalkan anda dengan sambungan yang perantinya tidak pernah muncul. Rujukan nmcli mendokumenkan subperintah import dan nama jenis yang diterima. Jika type wireguard ditolak terus, binaan itu lebih lama daripada ciri ini, dan langkah yang betul ialah pakej pengedaran atau backport — bukan menyalin konfigurasi ke direktori sewenang-wenangnya dengan harapan sesuatu membacanya.

Baca sambungan OpenVPN, bukan .ovpn

Setelah sambungan wujud, baca tetapan yang dihurai dan bukan membaca semula fail: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Anda mahu remote dan port, pengangkutan, bahan identiti — ca, cert, key, tls-auth atau tls-crypt — dan kaedah pengesahan. Pada profil dengan kata laluan kunci peribadi, tambah sudo nmcli --show-secrets connection show "Work VPN" dan lihat secret flag: 0 ialah none, jadi rahsia terletak dalam keyfile; 1 ialah agent-owned; 2 ialah not-saved, bermakna ia tidak pernah ditulis ke keyfile; 4 ialah not-required, bermakna tiada rahsia diperlukan sama sekali. Ia bit, bukan skala, jadi 3 hanyalah agent-owned tambah not-saved. Rahsia yang bertanya sekali setiap sesi ialah agent-owned (1), dengan ejen memintanya; tiada nombor bendera berasingan untuk itu. Ketidakpadanan bendera ialah sebab biasa sesuatu profil bersambung dari applet desktop dan gagal dari skrip atau semasa but.

Cara terpantas melihat apa yang digugurkan penghurai ialah meminta pemalam menulis fail itu semula dan kemudian membandingkannya: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktif yang hilang dalam perbezaan itu tidak akan wujud semasa sambungan. Hook ialah suspek biasa — script-security, up, down dan route-up menjangkakan skrip yang berjalan dengan hak tinggi dan sengaja tidak dibawa. Jangan rendahkan pengesahan atau beri keistimewaan tambahan supaya import berjaya; pilihan yang tidak disokong biasanya mencerminkan set ciri pemalam dan bukan pelayan yang tidak dapat dicapai. Pindahkan tingkah laku itu ke skrip dispatcher NetworkManager atau ke dasar di pihak pelayan.

Sahkan juga medan identiti terselamat: rujukan CA, remote-cert-tls dan apa-apa semakan nama yang diharapkan oleh profil. Sambungan yang naik tanpa itu mungkin bercakap dengan apa sahaja yang menjawab pada alamat tersebut.

Baca sambungan WireGuard, bukan fail wg-quick

Fail wg-quick ialah format dengan semantik shell; sambungan yang diimport ialah satu set tetapan. PrivateKey menjadi kunci peribadi antara muka, Address menjadi satu atau lebih alamat IPv4 dan IPv6, DNS dipetakan kepada sifat resolver NetworkManager, MTU dipetakan kepada wireguard.mtu (nilai lalai wg-quick sendiri ialah 1420), dan setiap blok peer menjadi entri peer dengan kunci awam, endpoint, IP yang dibenarkan dan persistent keepalive. Cetak apa yang disimpan dengan nmcli --show-secrets connection show wg0; jika senarai peer tidak muncul dalam output itu, baca keyfile:

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

Yang tidak terselamat ialah separuh shell wg-quick. PreUp, PostUp, PreDown, PostDown dan Table ialah tingkah laku alat itu, bukan atribut antara muka WireGuard, jadi tiada apa menjalankannya selepas import. Jika asal menggunakan Table = off untuk membiarkan laluan lalai, keluaran NetworkManager terbaharu menyediakan ip4-auto-default-route dan ip6-auto-default-route untuk tujuan yang sama; tetapkan secara eksplisit daripada menganggap sambungan berkelakuan seperti skrip. Hook yang menolak laluan tersuai memerlukan laluan itu dalam tetapan penghalaan sambungan, jika tidak ia akan hilang begitu sahaja.

Beri sambungan tepat satu pemilik

Kegagalan susulan klasik ialah sambungan yang berfungsi sehingga but seterusnya lalu berputar. Biasanya [email protected] masih diaktifkan daripada percubaan terdahulu, atau klien vendor menjalankan daemonnya sendiri, dan dua pemilik menulis laluan dan DNS untuk destinasi yang sama. NetworkManager menetapkan resolver melalui laluannya sendiri, wg-quick menulis melalui resolvconf, dan penulis terakhir menang — jadi penyelesaian nama berfungsi, kemudian berhenti, kemudian berfungsi semula. Semak systemctl status wg-quick@wg0, nmcli connection show --active dan ip link show type wireguard, kemudian lumpuhkan pemilik kedua daripada menala metriknya.

Jika anda benar-benar memerlukan kedua-duanya, beri mereka antara muka berasingan dan IP dibenarkan yang tidak bertindih, dan biarkan tepat salah satu memasang laluan lalai. Dua laluan lalai dengan metrik berbeza bukan split tunnel; ia perlumbaan yang ditentukan oleh perkhidmatan yang bermula kedua. Dan selepas menyambung semula, periksa semula keadaan yang digunakan — suntingan resolver manual sekali jalan yang membuat semuanya berfungsi bukan bukti bahawa import itu lengkap.

Sahkan dengan trafik dan bertahan daripada but semula

Naikkan sambungan dengan nmcli connection up "Work VPN", kemudian baca keadaan, alamat dan laluan daripada mempercayai ikon: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default dan carian sebenar bagi nama yang hanya terurai di dalam terowong. Handshake atau ping yang berjaya hanya membuktikan kriptografi berfungsi; ia tidak berkata apa-apa tentang penghantaran, awalan split tunnel atau DNS peribadi, dan itulah bahagian yang biasanya rosak.

Kemudian but semula dan ulangi. Tingkah laku autoconnect, antara muka yang dinamakan semula dan pemalam yang dimuatkan selepas peranti semuanya kegagalan yang hanya anda lihat pada but bersih. journalctl -u NetworkManager -b --no-pager | tail -n 40 menunjukkan apa yang dilakukan daemon dengan sambungan ini dalam but ini. Untuk komputer kedua, salin keyfile dan kekalkannya milik root dengan mod 600, atau gunakan nmcli connection export untuk OpenVPN dan import semula .ovpn yang terhasil — laluan eksport tiada persamaan WireGuard, jadi arah itu ialah salinan fail atau import baharu daripada asal yang dilindungi.

Versi pendek, mengikut urutan: sahkan pemalam atau versi NetworkManager, import dari laluan mutlak, baca tetapan yang dihurai termasuk secret flag, bandingkan eksport OpenVPN dengan asal, semak hook dan laluan di pihak WireGuard, lumpuhkan mana-mana pemilik kedua, kemudian selepas but semula sahkan penyelesaian nama dan jadual laluan. Apabila sambungan melepasi semua itu, fail profil yang memulakannya boleh kembali ke storan yang dilindungi.