OpenVPN sanoo active (exited)? Etsi käynnistämäsi instanssi

Tarkistat tunnelin, ajat systemctl status openvpn ja saat active (exited) ilman Main PID:tä ja tyhjällä prosessilistalla. Luonteva tulkinta on, että palvelu käynnistyi ja kuoli, joten avaat unitin, löydät /bin/true:n ja päättelet, että paketti on rikki. Debianin paketoinnissa tuo tila on wrapper, joka toimii suunnitellusti, ja tunneli elää yhdessä sen käynnistämistä instanssi-uniteista. Koosteyksikkö ei koskaan kerro, mikä instanssi sen rakensi.

Mitä active (exited) tällä unitilla todella tarkoittaa

Paketoitu unit on kertaluonteinen: sen ExecStart on /bin/true, ja RemainAfterExit=yes pitää valmiin unitin raportoituna tilassa active (exited). Poista tuo direktiivi, niin sama onnistunut /bin/true-tehtävä päättyy tilaan inactive (dead), joka on täsmälleen se tila, jota ihmiset odottavat ja lukevat väärin vastakkaiseen suuntaan. Komento on paikkamerkki, ja unit raportoi työstä, jota muut unitit tekevät. Mikään tuossa järjestelyssä ei ole rikki, ja /bin/true:n korvaaminen muuttaa paketointisopimusta, ei tunnelia.

Wrapper delegoi. Se käynnistää instanssi-unitit, jotka paketin konfiguraatio tai sen systemd-generaattori toimittaa, minkä vuoksi tyhjä prosessilista ei todista tunnelista mitään. Kun instanssia ei ole valittu, wrapper onnistuu silti eikä silti käynnistä mitään. Tila vastaa siihen, ajoiko wrapper, ei siihen, onko tunnelia olemassa.

Lue status-tulosteen kolme riviä etkä suluissa olevaa sanaa. Loaded nimeää unit-tiedoston, jonka systemd luki, Active kantaa viimeisimmän onnistuneen ajon aikaleiman, ja puuttuva Main PID sopii päättyneeseen kertaluonteiseen tehtävään. Nuo kolme riviä ovat myös tapa erottaa tämä wrapper palvelusta, joka kaatui sekunti käynnistyksen jälkeen.

Listaa unitit ennen kuin luet statusin uudelleen

Kysy systemdiltä, mitä on olemassa, ennen kuin kysyt, mitä on käynnissä. Malli voi olla asennettu, vaikka yhtään instanssia ei ole luotu, ja vain luotu unit kantaa tunnelia. Aloita ladatusta joukosta:

systemctl list-units 'openvpn*'

Tuo lista on se, mitä systemd on tällä hetkellä ladannut, ja se on lähimpänä tunnelien luetteloa. Asennetut unit-tiedostot vastaavat eri kysymykseen, ja tuo lista näyttää yhä mallin, kun mitään ei ole luotu:

systemctl list-unit-files 'openvpn*'

Lue molemmat listat yhdessä, sillä malli toisessa ja instanssi ensimmäisessä ovat eri vastauksia. Olemassa oleva malli ja käynnissä oleva instanssi eivät ole sama tosiasia, ja vain jälkimmäinen tarkoittaa tunnelia. Pakettien asettelut vaihtelevat myös jakelujen ja OpenVPN-versioiden välillä. Vanhempi openvpn@-malli, erillinen client- ja server-pari ja jakelun wrapper voivat kaikki olla laillisia omassa paketissaan.

Sovita omaan koneeseesi, älä löytämääsi oppaaseen. Instanssin nimi jonkun toisen tulosteessa voi olla office, kun sinun on home tai work. Siirtyy menetelmä, ei merkkijono.

Seuraa instanssin nimi tiedostoon, jonka se lukee

Ylävirran client-mallissa unitin työhakemisto on /etc/openvpn/client ja sen komento ottaa sieltä %i.conf:n, joten openvpn-client@office lukee tiedoston /etc/openvpn/client/office.conf. Vahvista tämä kartoitus asennetusta unitista sen sijaan että luottaisit esimerkkiin, sillä mallisi voi olla vanhempi tai jakelun uudelleenkirjoitus:

systemctl cat [email protected]

Lue drop-in-tiedostot, jotka näkyvät tuon tulosteen lopussa, sillä .d/-hakemiston alla oleva tiedosto voi muuttaa ExecStartia, työhakemistoa tai konfiguraatiopolkua. Profiili, jonka latasit nimellä office.ovpn, ei ole tiedosto, jonka instanssi avaa. Tämä ero on tavallinen syy siihen, että virhe nimeää polun, jota et koskaan muokannut.

Profiilin sisäiset suhteelliset polut ovat seuraava ansa. Pää tiedoston siirtäminen ja ca-, cert- ja key-viittausten jättäminen suhteellisiksi vaihtaa puuttuvan tiedoston virheen toiseen puuttuvan tiedoston virheeseen. Jälkimmäinen osoittaa tiedostoon, jonka olit varma olevan olemassa, ja siksi profiilin hakemisto on tärkeämpi kuin tiedoston nimi.

Käynnistä se ja lue sitten kyseisen instanssin loki

Käynnistä instanssi, jonka juuri tarkistit, sillä koosteyksikön loki ei sisällä tunnelin virheitä. Lue sitten tämän käynnistyksen loki ja etsi siinä järjestyksessä konfiguraatiovirhe, tiedoston käyttöoikeusvirhe ja yhteysvirhe, sillä kukin epäonnistuu käynnistyksen eri vaiheessa.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Käynnistäminen ja käyttöönotto ovat eri päätöksiä: start ajaa unitin nyt, enable järjestää seuraavan käynnistyksen ja enable --now tekee molemmat yhdessä vaiheessa. daemon-reload lukee unit-määrittelyt uudelleen eikä käynnistä käynnissä olevaa prosessia uudelleen eikä ota muokattua profiilia käyttöön. Kun olet muuttanut profiilia, käynnistä instanssi uudelleen, sillä se lukee tiedoston uudelleen.

Älä laita toista hallintaa samaan tunneliin

NetworkManager ja OpenVPN 3 -istuntojen hallinnat omistavat oman yhteyden tilansa, ja systemd-instanssi niiden vieressä asettaa samaan tunneliin kaksi omistajaa. Oire on tunneli, joka nousee ja korvataan sekunteja myöhemmin, tai sellainen, joka kieltäytyy pysymästä pysäytettynä. Valitse hallinta, jonka jakelusi dokumentoi työpöydälle, ja käytä systemdiä tarkoituksella palvelimella.

Tarkista olemassa oleva omistaja ennen instanssin käynnistämistä. Kun työpöydän applet näyttää yhteyden, käynnistämäsi instanssi kilpailee sen kanssa sen sijaan että täydentäisi sen. Poista käytöstä hallinta, jota et käytä, sen sijaan että ajaisit molempia ja toivoisit järjestyksen pitävän. Tämä ristiriita selittää myös lokit, joissa tunneli muodostetaan ja puretaan sitten prosessilla, jota et koskaan käynnistänyt.

Vastaa alkuperäiseen kysymykseen instanssin nimellä, sen lukemalla tiedostolla ja epäonnistuneella lokirivillä. OpenVPN:n huomautukset systemd-integraatiosta kuvaavat mallin asettelun ja tiedostokartoituksen, jonka kautta instanssin nimi ratkeaa.