OpenVPN ei käynnisty eikä virhettä näy? Katso journalia

Komento palaa, palvelu näkyy epäonnistuneena, eikä terminaaliin tule mitään selityksen tapaista. Se hiljaisuus on oire, jota ihmiset kuvaavat sanoilla «OpenVPN ei käynnisty», eikä se lähes koskaan tarkoita, että ohjelma kuoli sanomatta mitään. Se tarkoittaa, että viesti meni kanavaan, jota et lukenut, tai että se, minkä käynnistit, ei ollut se, minkä konfiguroit. Molemmat tapaukset voi diagnosoida alle minuutissa, kun lopetat profiilin pitämisen epäiltynä.

Neljä paikkaa nielee tulosteen: unitin journal, yhteyden omistava liitännäinen, tunnelin toinen pää ja eri binääri kuin se, jonka luulet olevan käynnissä. Jokaisella on oma tarkistuksensa.

Hiljaisuus tarkoittaa, että et seurannut oikeaa kanavaa

Etualalla tehty kutsu tulostaa terminaaliisi. Unit tulostaa journaliin, ja epäonnistunut unit voi poistua ennen kuin kirjoittaa yhtään mitään, jos vika on siinä, miten se käynnistettiin eikä siinä, mitä sille sanottiin. Ero on tärkeä: ei yhtään journal-merkintää tarkoittaa, että prosessi ei koskaan oikeasti käynnistynyt, kun taas yksi merkintä ja sen jälkeen poistuminen tarkoittaa, että se käynnistyi ja hylkäsi jotain.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Lisää systemctl show -p Result -p ExecMainStatus openvpn-client@office erottaaksesi puhtaan poistumisen signaalista. Tila 1 ja Result=exit-code on ohjelman päätös; Result=signal tai aikakatkaisu viittaavat sen sijaan ympäristöön, eikä mikään profiilin muokkaus muuta sitä. Kirjaa molemmat arvot ennen minkään uudelleenkäynnistämistä, koska uudelleenkäynnistys pyyhkii sen ohimenevän tilan, joka ne tuotti.

Instanssin nimi on osa polkua

Paketoitu malliyksikkö ei ota tiedostopolkua. Se ottaa instanssin nimen, ja se nimi liitetään hakemistoon profiilin löytämiseksi: office ratkeaa muotoon /etc/openvpn/client/office.conf Debianin ja Ubuntun paketoinnissa. Tiedostoa nimeltä office-v2.conf käynnistettynä nimellä @office ei koskaan lueta, ja unit poistuu hiljaa, koska sen näkökulmasta ei ollut mitään tehtävää. Hakemisto eroaa asiakas- ja palvelintilassa, joten sama virhe osoittaa aivan muualle, kun vaihdat mallia.

Tämä eroavuus on yleisin hiljaisen epäonnistumisen lähde, ja se on profiilissa näkymätön, koska profiili on kunnossa. Listaa, mitä todella on olemassa, ja vertaa kahta nimeä merkki merkiltä, mukaan lukien paketoinnin odottama tiedostopääte.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Jos unit on käytössä mutta yhtään instanssia ei ole listattu, käyttöönotto itse voi viitata nimeen, joka myöhemmin nimettiin uudelleen. Oikean instanssin ottaminen uudelleen käyttöön riittää yleensä, ja jäljelle jäänyt vanha unit-tiedosto kannattaa poistaa, jotta se ei hämmentä seuraavaa ihmistä. Jäljelle jäänyt unit-tiedosto on pieni asia, joka maksaa jollekin myöhemmin tunnin.

Kun liitännäinen omistaa tunnelin, terminaali ei näe mitään

Työpöytäsovelman apetista käynnistetyn yhteyden omistaa NetworkManager, ja sen OpenVPN-tuloste menee kyseisen palvelun journaliin eikä mihinkään avaamaasi shelliin. Asiakkaan käsin ajaminen ja tyhjän näkeminen on odotettua tuossa järjestelyssä, koska käsin ajettu prosessi ei ole se, joka kantaa yhteyttä.

Etsi journalista palvelu, joka omistaa sen, ja toista sitten jäsennys luettavalla tarkkuudella. Kaksi alla olevaa komentoa katsovat saman epäonnistumisen eri omistajia.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Erillinen ajo on viestien lukemista varten, ei hallitun yhteyden korvaamiseen, ja ne kaksi eroavat jälkeenpäin: DNS-integraatio, reitit ja elinikä kuuluvat liitännäiselle. Jäsennysvirheen korjaaminen erillisessä ajossa ei korjaa automaattisesti nimien selvitystä, kun apetti ottaa hallinnan, joten pidä kaksi havaintoa erillään.

Kaksi binääriä, yksi PATH

Käsin käännetty asennus hakemistossa /usr/local voittaa shell-kutsussa, koska /usr/local/sbin tulee ennen /usr/sbin Ubuntun oletus-PATHissa. Unit ei käytä sinun PATHiasi; se suorittaa absoluuttisen polun, joka on kirjoitettu ExecStart. Joten terminaalissasi toimiva versio ja palveluna epäonnistuva versio voivat olla todella eri ohjelmia.

Vertaa kahta ennen kuin rakennat mitään uudelleen. Kolmas komento on se, joka ratkaisee väitteen.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Vielä yksi ympäristöero piilee samassa paikassa. Paketoitu unit nojaa /run alla olevaan ajonaikaiseen hakemistoon, jonka systemd luo sille; käsin kirjoitettu korvaava unit, joka jättää tämän asetuksen pois, voi epäonnistua ennen kuin avaa yhtäkään tiedostoa, ja epäonnistuminen näyttää yleiseltä torjunnalta ilman mitään OpenVPN-viestiä.

Epäonnistumiset, joista asiakasohjelma ei voi kertoa

Jotkin lopputulokset ratkaistaan kaukopäässä. Yhdyskäytävä, joka vastaa HTTP-tilalla ja sulkee yhteyden, on kertonut omasta tilastaan, ja hyödyllinen seuraava askel on sen loki tai tunnistetietojen takana oleva tili, ei paikalliset tiedostosi. Siinä skenaariossa mikään paikallinen ei ole rikki, ja profiilin muokkaaminen kompensoimiseksi vaikeuttaa seuraavaa diagnoosia. Lue se loki ennen kuin kosket asiakkaan kokoonpanoa.

Toinen hiljainen tapaus on asiakasohjelma, joka toimii oikein. Asiakastilassa oleva tunneli ei koskaan kuuntele porttia, joten avointa kuuntelijaa odottava tarkistus ei raportoi mitään ja näyttää epäonnistumiselta. Vahvista, minkä tilan käynnistit, ennen kuin teet johtopäätöksen tyhjästä porttiluettelosta.

Käy kerrokset järjestyksessä: onko unit olemassa ja onko instanssin nimi oikein, pääsikö mitään journaliin tai tiedostoon --log, mikä binääri ja profiili todella käynnistyi, ja onko epäonnistuminen paikallinen vai kaukainen. Jokainen vastaus poistaa yhden kerroksen. Profiilista aloittaminen tarkoittaa tiedoston uudelleenkirjoittamista, jota ei ehkä koskaan avattu.