OpenVPN Ubuntun käynnistyksessä: NetworkManager vai systemd?

Useimmat oppaat esittävät valinnan kosmeettisena: joko annat NetworkManagerin nostaa tunnelin tai otat systemd-instanssin käyttöön ja se on siinä. Kaksi polkua eroavat yhdessä asiassa, joka ratkaisee tuloksen näytöttömässä koneessa, eikä sillä ole mitään tekemistä sen kanssa, kumpi työkalu on uudempi. NetworkManager avaa salaisuuksia istunnon kautta; systemd-instanssilla ei ole istuntoa avattavaksi. Valitse se, jonka salaisuuksien käsittely sopii edessäsi olevaan koneeseen.

Kaikki muu reittien asennuksesta uudelleenyhdistämisen toimintaan seuraa tuosta ensimmäisestä päätöksestä.

Avainrengas on ero, jota kukaan ei mainitse

Kun NetworkManager omistaa VPN-profiilin, salasana voi asua kirjautumisen avainrenkaassa, joka avautuu, kun käyttäjä kirjautuu sisään. Se toimii hyvin kannettavassa: henkilö on paikalla, avainrengas aukeaa, tunneli nousee. Palvelimella, joka käynnistyy valvomatta, ei ole ketään avaamaan mitään, joten profiili odottaa salaisuutta, joka ei koskaan saavu. Yhteys näyttää määritetyltä eikä aktivoidu koskaan.

systemd-instanssi välttää ongelman lukemalla tunnistetiedoston levyltä, mikä tekee tiedostosta sen, mitä suojaat. chmod 400 ja rootin omistus on vähimmäisvaatimus, ja tiedoston tulisi pysyä poissa varmuuskopioista ja levykuvapohjista, joita et hallitse.

VPN:n liittäminen yhteyteen ei takaa käynnistystä

Valitse kohdassa nm-connection-editor VPN:n sijaan langallinen tai langaton yhteys, avaa General-välilehti, valitse automaattinen VPN-yhteys ja nimeä profiili. Sitten NetworkManager aktivoi VPN:n toissijaisena yhteytenä, kun ensisijainen saavuttaa yhdistetyn tilan. Se on riippuvuus, ei palomuurisääntö. Paketit voivat silti lähteä sinä sekunteina ennen kuin tunneli on ylhäällä, ja tallennettu salaisuus, jonka avaaminen epäonnistuu, jättää koneen verkkoon ilman sitä.

Jos vaatimuksena on, ettei mikään lähde ilman tunnelia, sano se ja rakenna kill switch, koska tämä asetus ei sellaista anna. Testaa myös keskeytys ja jatkaminen, sillä toissijainen yhteys arvioidaan uudelleen paluumatkalla.

systemd-instanssi tarvitsee täsmäävän tiedostonimen

Sijoita profiili asiakashakemistoon, jota paketti odottaa, esimerkiksi /etc/openvpn/client/office.conf, ja viittaa sisältä tunnistetiedostoon komennolla auth-user-pass office.cred. Instanssin nimi on tiedostonimi ilman päätettä, joten openvpn-client@office lukee tiedoston office.conf. Ota se käyttöön komennolla sudo systemctl enable --now openvpn-client@office ja vahvista vastaavuus komennolla systemctl cat openvpn-client@office sen sijaan, että luottaisit blogin esimerkkiin.

Profiilin sisäiset polut ratkaistaan yksikön työhakemiston, eivät profiilin itsensä suhteen, joten suhteellinen ca- tai auth-user-pass-rivi voi epäonnistua käynnistyksessä, vaikka se toimii käsin testattaessa. Käytä absoluuttisia polkuja kaikkeen, mitä yksikön on löydettävä. Lue sitten journalctl -u openvpn-client@office -b todellisen käynnistyksen jälkeen; yksikkö, joka ilmoittaa olevansa aktiivinen ilman tunnelia, nimeää yleensä puuttuvan tiedoston siinä lokissa.

Vanhemmat paketit toimittavat eri mallipohjan nimen, joten systemctl list-unit-files 'openvpn*' ratkaisee, kumpi tässä isännässä on olemassa.

Uudelleenyhdistämisen toiminta on erillinen päätös

Profiili, jossa on ping-restart, rakentaa tunnelin uudelleen sen katkettua, ja yksikkö, jossa on uudelleenkäynnistysdirektiivi, tekee jotain vastaavaa palvelutasolla. Ne ovat käytäntöjä, jotka valitset, eivät oletuksia, jotka perit. Jos yhteyden pitäisi nousta vain pyynnöstä, poista uudelleenkäynnistyksen toiminta tarkoituksella ja kirjoita perustelu. Jos yksikkö käynnistyy ennen kuin verkko on käyttökelpoinen, se tarvitsee uudelleenyrityskäytännön, koska yksi epäonnistunut yritys käynnistyksessä ei toistu itsestään.

Pysäyttäminen on yhtä kirjaimellista: sudo systemctl disable --now openvpn-client@office pysäyttää käynnissä olevan instanssin ja poistaa käynnistyslinkin. Pelkkä poistaminen käytöstä jättää tunnelin käyntiin seuraavaan uudelleenkäynnistykseen asti, mikä yllättää jokaisen, joka testaa poistamalla käytöstä ja katsoo rajapinnan pysyvän ylhäällä.

Käynnistä uudelleen ja tarkista sitten neljä asiaa järjestyksessä

Palvelun uudelleenkäynnistys testaa palvelun; koneen uudelleenkäynnistys testaa käynnistyspolun. Vahvista uudelleenkäynnistyksen jälkeen, että yksikkö nousi, sitten että etäaliverkolle on reitti, sitten minkä osoitteen kone esittää internetille ja lopuksi että nimet ratkeavat tunnelin kautta. Nämä neljä tarkistusta epäonnistuvat siinä järjestyksessä, kun jokin on vialla, mikä tekee ensimmäisestä epäonnistumisesta hyödyllisen.

Aktiivinen yksikkö ilman reittiä tarkoittaa yleensä, että profiili yhdistyi mutta palvelin ei työntänyt yhtään reittiä, tai että reitti asennettiin rajapintaan, joka katosi myöhemmin. Reitti, jossa nimien haku ei toimi, osoittaa DNS-määritykseen eikä itse tunneliin.

Päätä etukäteen, mitä pitäisi tapahtua, kun tunneli ei voi nousta. Paluu tavalliseen yhteyteen on käytäntö, ja se pitäisi kirjata sen sijaan, että se jätetään sille hallinnalle, joka käynnistyi ensin.