Importo en NetworkManager malsukcesas ĉe OpenVPN kaj WireGuard dosieroj

Mi elektis Importi el dosiero… en la agordoj de GNOME, elektis profilon kiu funkcias kun la kliento de la provizanto, kaj la dialogo fermiĝis sen aldoni ion al la listo. Sur dua tekkomputilo la importo finiĝis, la konekto aperis sub la nomo de la profilo, kaj poste ĝi malsukcesis ĉe la unua aŭtentiga peto. NetworkManager neniam rulas vian .ovpn aŭ wg-quick dosieron tiel, kiel ĝi estas. Ĝi transdonas la dosieron al analizilo, la analizilo konvertas ĝin al la propra konekta formato de NetworkManager, kaj de tiam la tunelo estas konstruata el tiu analizita objekto — sekretoj, vojoj, DNS kaj ĉio alia. Do la utila demando ne estas kial la dosiero estas difektita, sed ĉu la analizo okazis kaj kion ĝi konservis.

Kion la importo efektive faras kun la dosiero

Por OpenVPN, la analizilo loĝas en la kromaĵa pako, kaj la konekto kiun ĝi kreas montras al D-Bus servo kiel org.freedesktop.NetworkManager.openvpn. Sen kromaĵo, sen analizilo: la tipo estas nekonata al nmcli, kaj la grafika listo por aldoni VPN eble tute ne montras importan eron. WireGuard diferencas en unu grava punkto — NetworkManager havas proprajn WireGuard-agordojn ekde la serio 1.30, do ne ekzistas aparta kromaĵa pako, sed la legilo wg-quick ekzistas nur en konstruaĵoj kiuj liveras ĝin.

Ĉiel ajn, la dosiero estas legata unufoje. La rezulto estas skribata kiel keyfile sub /etc/NetworkManager/system-connections/, nomata laŭ la konekto, posedata de root kaj nelegebla por aliaj uzantoj ĉar ĝi enhavas la ŝlosilan materialon. Tiu keyfile nun estas la konekto; redakti la originalan .ovpn poste ŝanĝas nenion.

Tri simptomoj apartenas al tri malsamaj etapoj. Neniu importa ero aŭ nekonata tipo signifas ke mankas la kromaĵo aŭ la versio. Importa eraro kiu nomas direktivon signifas ke la analizilo legis la dosieron kaj malakceptis parton de ĝi. Konekto kiu ekzistas sed neniam aktiviĝas signifas ke la analizita objekto estas nekompleta aŭ ke la servilo malakceptas ĝin. Decidu kiun el la tri kazoj vi havas antaŭ ol redakti ion ajn.

Konfirmu la kromaĵon antaŭ ol sencimigi la profilon

Mankanta kromaĵo aspektas precize kiel difektita profilo, do unue kontrolu la pakon. En Debian kaj Ubuntu la subteno por OpenVPN venas kiel network-manager-openvpn plus labortabla helpilo; en Fedora la pakoj estas NetworkManager-openvpn kaj NetworkManager-openvpn-gnome; en Arch ĝi estas networkmanager-openvpn.

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

Poste importu el absoluta vojo: nmcli connection import type openvpn file /home/you/profile.ovpn. Relativaj vojoj kutime funkcias, sed ŝelo kiu ŝanĝis dosierujon transformas rapidan importon en ĉirkaŭvojon. Por WireGuard kontrolu nmcli --version kaj certiĝu ke la kerno-flanko ekzistas per modprobe wireguard; importo kiu sukcesas sur maŝino sen la modulo lasas vin kun konekto kies aparato neniam aperas. nmcli-referenco dokumentas la subkomandon import kaj la akceptitajn tipnomojn. Se type wireguard estas tuj malakceptata, la konstruaĵo estas pli malnova ol ĉi tiu funkcio, kaj la ĝusta paŝo estas distribua pako aŭ backport — ne kopii la agordon en arbitran dosierujon esperante ke io legos ĝin.

Legu la OpenVPN-konekton, ne la .ovpn

Kiam la konekto ekzistas, legu la analizitajn agordojn anstataŭ relegi la dosieron: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Vi volas la remote kaj la pordon, la transporton, la identan materialon — ca, cert, key, tls-auth aŭ tls-crypt — kaj la aŭtentigan metodon. Ĉe profilo kun pasvorto de privata ŝlosilo aldonu sudo nmcli --show-secrets connection show "Work VPN" kaj rigardu la secret-flagojn: 0 estas none, do la sekreto kuŝas en la keyfile; 1 estas agent-owned; 2 estas not-saved, kio signifas ke ĝi neniam estas skribata en la keyfile; 4 estas not-required, kio signifas ke neniu sekreto estas bezonata. Ili estas bitoj, ne skalo, do 3 estas simple agent-owned plus not-saved. Sekreto kiun oni demandas unufoje po seanco estas agent-owned (1), kun la agento petanta ĝin; ne ekzistas aparta flagnumero por tio. Miskongruo de flagoj estas la kutima kaŭzo ke profilo konektiĝas el la labortabla aplikaĵeto kaj malsukcesas el skripto aŭ ĉe starto.

La plej rapida maniero vidi kion la analizilo forĵetis estas peti la kromaĵon reskribi la dosieron kaj poste kompari ĝin: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktivoj kiuj malaperas en tiu diff ne ekzistos ĉe konekta tempo. Hokoj estas la kutimaj suspektatoj — script-security, up, down kaj route-up atendas skripton rulatan kun altigitaj rajtoj kaj estas intence ne transdonataj. Ne malaltigu la kontrolon kaj ne donu kromajn privilegiojn por sukcesigi importon; nesubtenata opcio kutime spegulas la funkciaron de la kromaĵo, ne neatingeblan servilon. Movu tiun konduton en NetworkManager-dispatcher-skripton aŭ en serviloflankan politikon.

Ankaŭ konfirmu ke la identaj kampoj postvivis: la CA-referenco, remote-cert-tls kaj ajna nomkontrolo sur kiu la profilo fidis. Konekto kiu leviĝas sen ili eble parolas kun io ajn kio respondas ĉe tiu adreso.

Legu la WireGuard-konekton, ne la wg-quick-dosieron

wg-quick-dosiero estas formato kun ŝela semantiko; la importita konekto estas aro da agordoj. PrivateKey iĝas la privata ŝlosilo de la interfaco, Address iĝas unu aŭ pluraj IPv4 kaj IPv6 adresoj, DNS mapiĝas al la resolver-ecoj de NetworkManager, MTU mapiĝas al wireguard.mtu (la propra defaŭlto de wg-quick estas 1420), kaj ĉiu peer-bloko iĝas peer-ero kun publika ŝlosilo, endpoint, permesitaj IP-oj kaj persistent keepalive. Presu kion oni konservis per nmcli --show-secrets connection show wg0; se la peer-listo ne aperas en tiu eligo, legu la keyfile:

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

Kio ne postvivas estas la ŝela duono de wg-quick. PreUp, PostUp, PreDown, PostDown kaj Table estas konduto de tiu ilo, ne atributoj de WireGuard-interfaco, do nenio rulas ilin post importo. Se la originalo uzis Table = off por lasi la defaŭltan vojon trankvila, novaj NetworkManager-eldonoj elmetas ip4-auto-default-route kaj ip6-auto-default-route por la sama celo; agordu ilin eksplicite anstataŭ supozi ke la konekto kondutas kiel la skripto. Hoko kiu puŝis propran vojon bezonas tiun vojon en la enkursigaj agordoj de la konekto, alie ĝi simple mankos.

Donu al la konekto precize unu posedanton

La klasika posta fiasko estas konekto kiu funkcias ĝis la sekva starto kaj poste enlupiĝas. Kutime [email protected] ankoraŭ estis ŝaltita el antaŭa eksperimento, aŭ provizanta kliento lanĉis sian propran demonon, kaj du posedantoj skribis vojojn kaj DNS por la sama celo. NetworkManager agordas la resolveron laŭ sia propra vojo, wg-quick skribas tra resolvconf, kaj la lasta skribinto gajnas — do nomrezo funkcias, poste haltas, poste denove funkcias. Kontrolu systemctl status wg-quick@wg0, nmcli connection show --active kaj ip link show type wireguard, poste malŝaltu la duan posedanton anstataŭ agordi ĝian metric.

Se vi vere bezonas ambaŭ, donu al ili apartajn interfacojn kaj disajn permesitajn IP-ojn, kaj lasu precize unu el ili instali la defaŭltan vojon. Du defaŭltaj vojoj kun malsamaj metric ne estas split tunnel; ĝi estas konkurso decidata de la servo kiu startas dua. Kaj post rekonekto, denove inspektu la aplikitan staton — unufoja permana redakto de la resolvero kiu igas aferojn funkcii ne estas pruvo ke la importo estas kompleta.

Kontrolu per trafiko kaj postvivu restartigon

Levigu la konekton per nmcli connection up "Work VPN", poste legu staton, adreson kaj vojojn anstataŭ fidi la ikonon: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, kaj veran serĉon de nomo kiu solviĝas nur ene de la tunelo. Handshake aŭ sukcesa ping pruvas nur ke la kriptografio funkcias; ĝi diras nenion pri plusendado, split-tunnel-prefiksoj aŭ privata DNS, kaj ĝuste tiuj partoj kutime rompiĝas.

Poste restartigu kaj ripetu. La konduto de autoconnect, alinomita interfaco kaj kromaĵo kiu ŝargiĝas post la aparato estas ĉiuj fiaskoj videblaj nur ĉe pura starto. journalctl -u NetworkManager -b --no-pager | tail -n 40 montras kion la demono faris kun ĉi tiu konekto en ĉi tiu starto. Por dua komputilo kopiu la keyfile kaj tenu ĝin posedata de root kun reĝimo 600, aŭ uzu nmcli connection export por OpenVPN kaj reimportu la rezultan .ovpn — la eksporta vojo ne havas WireGuard-ekvivalenton, do tiu direkto estas dosierkopio aŭ freŝa importo el la protektita originalo.

Mallonga versio, laŭ ordo: konfirmu la kromaĵon aŭ la version de NetworkManager, importu el absoluta vojo, legu la analizitajn agordojn inkluzive de secret-flagoj, komparu la OpenVPN-eksporton kun la originalo, kontrolu hokojn kaj vojojn ĉe la WireGuard-flanko, malŝaltu ĉiun duan posedanton, kaj poste post restartigo kontrolu nomrezon kaj la vojtablon. Kiam konekto trapasas ĉion tion, la profila dosiero kiu komencis ĝin povas reveni al protektita stokado.