NetworkManagerin tuonti epäonnistuu OpenVPN- ja WireGuard-tiedostoilla

Valitsin Tuo tiedostosta… GNOME-asetuksissa, valitsin profiilin, joka toimii toimittajan asiakasohjelman kanssa, ja valintaikkuna sulkeutui lisäämättä mitään luetteloon. Toisella kannettavalla tuonti valmistui, yhteys ilmestyi profiilin nimellä ja sitten se epäonnistui ensimmäisessä todennuspyynnössä. NetworkManager ei koskaan suorita .ovpn- tai wg-quick-tiedostoasi sellaisenaan. Se antaa tiedoston jäsentimelle, jäsennin muuntaa sen NetworkManagerin omaan yhteysmuotoon, ja siitä lähtien tunneli rakennetaan tästä jäsennetystä objektista — salaisuudet, reitit, DNS ja kaikki muu. Hyödyllinen kysymys ei siis ole, miksi tiedosto on rikki, vaan tapahtuiko jäsennys ja mitä se säilytti.

Mitä tuonti oikeastaan tekee tiedostolle

OpenVPN-ohjelman kohdalla jäsennin sijaitsee lisäosapaketissa, ja luotu yhteys osoittaa D-Bus-palveluun, kuten org.freedesktop.NetworkManager.openvpn. Ei lisäosaa, ei jäsennintä: tyyppi on nmclille tuntematon, eikä graafinen VPN:n lisäysluettelo välttämättä näytä lainkaan tuontimerkintää. WireGuard eroaa yhdessä tärkeässä kohdassa — NetworkManagerilla on omat WireGuard-asetukset 1.30-sarjasta lähtien, joten erillistä lisäosapakettia ei ole, mutta wg-quick-lukija on vain niissä koosteissa, jotka toimittavat sen.

Kummassakin tapauksessa tiedosto luetaan kerran. Tulos kirjoitetaan keyfile-tiedostona hakemistoon /etc/NetworkManager/system-connections/, nimetään yhteyden mukaan, omistaa root, eivätkä muut käyttäjät voi lukea sitä, koska se sisältää avainmateriaalin. Tämä keyfile on nyt yhteys; alkuperäisen .ovpn muokkaaminen jälkeenpäin ei muuta mitään.

Kolme oiretta kuuluu kolmeen eri vaiheeseen. Ei tuontimerkintää tai tuntematon tyyppi tarkoittaa, että lisäosa tai versio puuttuu. Tuontivirhe, joka nimeää direktiivin, tarkoittaa, että jäsennin luki tiedoston ja hylkäsi osan siitä. Yhteys, joka on olemassa mutta ei koskaan aktivoidu, tarkoittaa, että jäsennetty objekti on puutteellinen tai palvelin hylkii sitä. Päätä, mikä kolmesta tapauksesta sinulla on, ennen kuin muokkaat mitään.

Vahvista lisäosa ennen profiilin virheenkorjausta

Puuttuva lisäosa näyttää täsmälleen rikkoutuneelta profiililta, joten tarkista ensin paketti. Debianissa ja Ubuntussa OpenVPN-tuki toimitetaan pakettina network-manager-openvpn sekä työpöytäavustaja; Fedorassa paketit ovat NetworkManager-openvpn ja NetworkManager-openvpn-gnome; Archissa se on networkmanager-openvpn.

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

Tuo sitten absoluuttisesta polusta: nmcli connection import type openvpn file /home/you/profile.ovpn. Suhteelliset polut yleensä toimivat, mutta hakemistoa vaihtanut komentotulkki muuttaa nopean tuonnin kiertotieksi. WireGuardin kohdalla tarkista nmcli --version ja varmista, että ydinpuoli on olemassa komennolla modprobe wireguard; tuonti, joka onnistuu koneella ilman moduulia, jättää sinut yhteyteen, jonka laite ei koskaan ilmesty. nmcli-viite dokumentoi import-alikomennon ja hyväksytyt tyyppinimet. Jos type wireguard hylätään heti, kooste on toimintoa vanhempi, ja oikea siirto on jakelupaketti tai backport — ei konfiguraation kopioiminen mielivaltaiseen hakemistoon toivoen, että jokin lukee sen.

Lue OpenVPN-yhteys, älä .ovpn-tiedostoa

Kun yhteys on olemassa, lue jäsennetyt asetukset sen sijaan, että lukisit tiedoston uudelleen: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Haluat remoten ja portin, transportin, identiteettimateriaalin — ca, cert, key, tls-auth tai tls-crypt — ja todennusmenetelmän. Profiilissa, jossa on yksityisen avaimen salasana, lisää sudo nmcli --show-secrets connection show "Work VPN" ja katso secret-lippuja: 0 on none, joten salaisuus on keyfilessä; 1 on agent-owned; 2 on not-saved, eli sitä ei koskaan kirjoiteta keyfileen; 4 on not-required, eli salaisuutta ei tarvita lainkaan. Ne ovat bittejä, eivät asteikko, joten 3 on yksinkertaisesti agent-owned plus not-saved. Salaisuus, jota kysytään kerran istunnossa, on agent-owned (1), jolloin agentti pyytää sitä; erillistä lippunumeroa sille ei ole. Lippujen epäsopivuus on tavallinen syy siihen, että profiili yhdistää työpöytäsovelmasta ja epäonnistuu komentosarjasta tai käynnistyksessä.

Nopein tapa nähdä, mitä jäsennin pudotti, on pyytää lisäosaa kirjoittamaan tiedosto takaisin ja sitten diffata se: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Direktiivit, jotka katoavat siinä diffissä, eivät ole olemassa yhdistämishetkellä. Hookit ovat tavallisia epäiltyjä — script-security, up, down ja route-up odottavat korotetuilla oikeuksilla ajettavaa komentosarjaa, eikä niitä siirretä tarkoituksella. Älä laske vahvistusta äläkä anna lisäoikeuksia, jotta tuonti onnistuisi; tukematon valinta heijastaa yleensä lisäosan ominaisuusjoukkoa, ei saavuttamatonta palvelinta. Siirrä tämä toiminta NetworkManagerin dispatcher-komentosarjaan tai palvelinpuolen käytäntöön.

Vahvista myös, että identiteettikentät säilyivät: CA-viite, remote-cert-tls ja mikä tahansa nimtarkistus, johon profiili luotti. Yhteys, joka nousee ilman niitä, saattaa puhua mille tahansa, mikä vastaa siinä osoitteessa.

Lue WireGuard-yhteys, älä wg-quick-tiedostoa

wg-quick-tiedosto on muoto, jolla on shell-semantiikka; tuotu yhteys on joukko asetuksia. PrivateKey:stä tulee liitännän yksityinen avain, Address:sta tulee yksi tai useampi IPv4- ja IPv6-osoite, DNS karttuu NetworkManagerin resolver-ominaisuuksiin, MTU karttuu wireguard.mtu:hun (wg-quickin oma oletus on 1420), ja jokaisesta peer-lohkosta tulee peer-merkintä, jossa on julkinen avain, endpoint, sallitut IP:t ja persistent keepalive. Tulosta tallennettu nmcli --show-secrets connection show wg0:lla; jos peer-luettelo ei näy siinä tulosteessa, lue keyfile:

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

Se, mikä ei säily, on wg-quickin shell-puoli. PreUp, PostUp, PreDown, PostDown ja Table ovat työkalun toimintaa, eivät WireGuard-liitännän attribuutteja, joten mikään ei suorita niitä tuonnin jälkeen. Jos alkuperäinen käytti Table = off jättääkseen oletusreitin rauhaan, uudemmat NetworkManager-julkaisut tarjoavat samaan tarkoitukseen ip4-auto-default-route ja ip6-auto-default-route; aseta ne nimenomaisesti sen sijaan, että olettaisit yhteyden käyttäytyvän kuin komentosarja. Hook, joka työnsi mukautetun reitin, tarvitsee sen reitin yhteyden reititysasetuksiin, muuten se yksinkertaisesti puuttuu.

Anna yhteydelle täsmälleen yksi omistaja

Klassinen jälkihäiriö on yhteys, joka toimii seuraavaan käynnistykseen ja menee sitten silmukkaan. Yleensä [email protected] oli vielä käytössä aiemmasta kokeesta tai toimittajan asiakasohjelma käynnisti oman daemoninsa, ja kaksi omistajaa kirjoitti reittejä ja DNS:ää samalle kohteelle. NetworkManager asettaa resolverin omalla polullaan, wg-quick kirjoittaa resolvconfin kautta, ja viimeinen kirjoittaja voittaa — joten nimien selvitys toimii, sitten pysähtyy, sitten toimii taas. Tarkista systemctl status wg-quick@wg0, nmcli connection show --active ja ip link show type wireguard ja poista sitten toinen omistaja käytöstä sen metricin säätämisen sijaan.

Jos todella tarvitset molempia, anna niille erilliset liitännät ja erilliset sallitut IP:t ja anna täsmälleen yhden niistä asentaa oletusreitti. Kaksi eri metricillä olevaa oletusreittiä ei ole split tunnel; se on kilpailu, jonka ratkaisee palvelu, joka käynnistyy toisena. Ja uudelleenyhdistämisen jälkeen tarkastele sovellettua tilaa uudelleen — kertaluonteinen manuaalinen resolver-muutos, joka saa asiat toimimaan, ei ole todiste siitä, että tuonti on täydellinen.

Vahvista liikenteellä ja selviydy uudelleenkäynnistyksestä

Nosta yhteys komennolla nmcli connection up "Work VPN" ja lue sitten tila, osoite ja reitit sen sijaan, että luottaisit kuvakkeeseen: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default ja todellinen sellaisen nimen kysely, joka selvitetään vain tunnelin sisällä. Handshake tai onnistunut ping todistaa vain, että salaus toimii; se ei kerro mitään edelleenlähetyksestä, split tunnelin etuliitteistä tai yksityisestä DNS:stä, ja juuri ne osat yleensä hajoavat.

Käynnistä sitten uudelleen ja toista. Autoconnect-käyttäytyminen, uudelleennimetty liitäntä ja lisäosa, joka latautuu laitteen jälkeen, ovat kaikki häiriöitä, jotka näet vain puhtaalla käynnistyksellä. journalctl -u NetworkManager -b --no-pager | tail -n 40 näyttää, mitä daemon teki tämän yhteyden kanssa tässä käynnistyksessä. Toista tietokonetta varten kopioi keyfile ja pidä se rootin omistuksessa tilassa 600, tai käytä nmcli connection export OpenVPN:lle ja tuo tuloksena oleva .ovpn uudelleen — vientipolulla ei ole WireGuard-vastinetta, joten tämä suunta on tiedostokopio tai uusi tuonti suojatusta alkuperäisestä.

Lyhyt versio järjestyksessä: vahvista lisäosa tai NetworkManager-versio, tuo absoluuttisesta polusta, lue jäsennetyt asetukset secret-lippuineen, vertaa OpenVPN-vientiä alkuperäiseen, tarkista hookit ja reitit WireGuardin puolella, poista kaikki toiset omistajat käytöstä ja vahvista sitten uudelleenkäynnistyksen jälkeen nimien selvitys ja reititystaulu. Kun yhteys läpäisee kaiken tämän, profiilitiedosto, josta se alkoi, voi palata suojattuun säilöön.