OpenVPN ei käynnisty: lue ensimmäinen rivi, älä asetuksia

Ensimmäisellä sekunnilla kuoleva VPN on aivan eri eläin kuin sellainen, joka yhdistää ja sitten epäonnistuu, ja tavallinen virhe on kohdella niitä samana. Täällä ei ole kättelyä, ei varmennevaihtoa eikä tarkasteltavaa reittiä. Yksi rivi journalissa ratkaisee, mikä useasta toisiinsa liittymättömästä korjauksesta pätee, ja sen ohittaminen maksaa iltapäivän sellaisen asetuksen muokkaamista, jota ei koskaan luettu. Lue se rivi ensin.

Kolme vain luku -komentoa vievät sinut sinne: ensin journalctl -u openvpn@server -b --no-pager, sitten systemctl status openvpn@server ja ss -lunp UDP-kuuntelijoita ja niiden omistajia varten.

Ensimmäinen rivi valitsee haaran

Porttiristiriita ja puuttuva binääri tappavat molemmat käynnistyksen sekunnissa, ja ne jättävät erilaiset ensimmäiset rivit. Viesti osoitteen jo käytössä olosta nimeää portin; puuttuva suoritettava tiedosto nimeää polun, jota ei enää ole; epäonnistunut ehto tai puuttuva asetustiedosto nimeää tiedoston. Ne kolme johtavat erilaisiin korjauksiin, eikä mikään niistä parane asiakasohjelman uudelleenasennuksella. Kopioi ensimmäinen epäonnistuminen muistiinpanoihisi ennen kuin ajat mitään muuta.

Varo uudelleenyrityssilmukkaa, joka kätkee alkuperäisen rivin. Yksikkö, jolla on uudelleenkäynnistyskäytäntö, voi haudata ensimmäisen epäonnistumisen tusinan identtisen alle, joten yksikön mukaan suodatettu ja ylhäältä luettu journalctl -b voittaa hännän.

Kuka muu pitää porttia 1194

Syyllinen ei yleensä ole toinen palvelin, jonka joku on tarkoituksella määrittänyt. Odota käsin käynnistettyä asiakasta, joka on yhä elossa toisessa päätteessä, toista profiilia, joka sattui valitsemaan saman portin, tai toimittajan nippua, jonka oma tunneli pitää porttia 1194. Pistokkeen omistaja näkyy kohdassa ss -lunp; anna tuo PID komennolle systemctl status, jotta tiedät, onko jokin yksikkö vastuussa. Laske se alas sen omasta ohjauspolusta signaalin sijaan.

Signaali yksikön hallitsemalle prosessille laukaisee yleensä uudelleenkäynnistyksen, ja sama epäonnistuminen palaa hetkiä myöhemmin uutena ongelmana. Käytä systemctl stop yksikölle, nipun omaa palvelukomentoa toimittajan asennukselle ja signaalia vain johonkin, jonka käynnistit itse käsin siinä kuoressa.

Poistamisen jälkeen jäljelle jääneet yksiköt

Poistaminen deletoi binäärit; käsin kirjoitetut yksikkötiedostot, tyypillisesti hakemistossa /etc/systemd/system, jäävät henkiin. Silloin Systemd yrittää uudelleen yksikköä, joka osoittaa polkuun, jota ei enää ole, ja viesti koskee tuota puuttuvaa tiedostoa eikä eilistä poistoa. systemctl status näyttää yksikön fragmentin polun lähellä yläreunaa, joten tarkista se komennolla dpkg -S ennen kuin poistat mitään. Kun orpo on poissa, systemctl daemon-reload ja systemctl reset-failed siivoavat tilan; muuten jokainen myöhempi tilantarkistus perii sen.

Kun which openvpn vastaa jollakin hakemistossa /usr/local, pelissä oleva binääri tuli toimittajan asentajalta eikä apt:lta. Sellainen asentaja tuo yleensä oman kuuntelijansa, oman käynnistysmerkintänsä ja oman asetushakemistonsa, joten näkyvän komennon poistaminen jättää pistokkeen varatuksi.

Poista se asennus toimittajan dokumentoimalla tavalla, varmista komennolla ss -lunp, että portti on vapaa, ja lisää jakelun asiakasohjelma vain jos tarvitset sitä.

Laita tila kuntoon ennen uutta yritystä

Siivoa epäonnistumistila ennen kuin teet siitä johtopäätöksiä: systemctl reset-failed poistaa laskurit, ja systemctl status raportoi sitten yksikön nykyisen tilan eikä sen historiaa. Käynnistä se kerran ja lue juuri sen ajon journal, älä koneen kokonaistilaa. Yksikkö, joka ilmoittaa olevansa aktiivinen, vaikka tunneli ei kuljeta mitään, on erillinen ongelma ja paljon yleisempi. Kaksi sulautuu virheraporteissa yhteen, koska molemmat päättyvät käyttäjän sanoihin, ettei VPN toimi.

Kirjaa valitsemasi haara: porttiristiriita, puuttuva binääri, puuttuvat asetukset. Seuraavalla kerralla tunnistaminen on nopeampaa.