Mikä OpenVPN-instanssi oikeastaan käyttää PiVPN-profiiliasi?

PiVPN kirjoittaa palvelinmäärityksen ja asiakasprofiilin ja poistuu sitten; siitä ei koskaan tule prosessia, joka kuljettaa liikennettäsi. Siksi epäonnistunut kättely, väärään päätepisteeseen soittava asiakas tai uudelleenkäynnistyksen jälkeen väärin palaava palvelu eivät selity asentajan valikoista. Ne oireet kuuluvat sille OpenVPN-demoniile, joka nyt on käynnissä, sille määritykselle, jonka se demoni todella latasi, ja sille lokille, johon se osoitettiin. Neljä vain luku -komentoa selvittävät asian yleensä, eikä mikään niistä muuta varmenteitasi tai avaimiasi.

Avustaja ja demoni ovat eri objekteja

Sekavuus on helppo selittää: yksi hakemisto sisältää tiedoston, jonka avustaja loi, tiedoston, jota demoni lukee, ja joskus molempien vanhentuneen kopion. Avustaja on provisiointiskripti. Se asentaa paketteja, kirjoittaa yksikkötiedostoja ja tulostaa asiakasprofiilin, ja sitten sen työ päättyy. Jäljelle jää merkintä palveluhallinnassa ja komentorivi.

Aloita systemd-isännässä aktiivisesta yksiköstä hakemistolistauksen sijaan. Nimi riippuu paketoinnista: Debian- ja Raspberry Pi OS -kuvat tarjoavat yleensä mallipohjaisen instanssin, kuten openvpn-server@server, kun taas vanhemmat asennukset käyttävät openvpn@server. Kysy hallinnalta, kumpi on käynnissä, sen sijaan että arvaisit tiedostonimestä.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lue ExecStart= tuosta tulosteesta. Se nimeää suoritettavan tiedoston ja valinnat, jotka hallinta todella käynnistää, mukaan lukien mahdollinen --config polku; lähellä oleva määritystiedosto, johon mikään komento ei viittaa, ei kuulu käynnissä olevaan tunneliin.

Seuraa määritysketjua, jonka demoni ratkaisi

OpenVPN ei skannaa hakemistoa asetusten varalta. Se lukee tiedoston, joka sille annetaan --config, seuraa kaikkia sen sisällä olevia config direktiivejä ja soveltaa sitten komentorivivalintoja. Käsikirja 2.6 kuvaa tämän järjestyksen, ja sillä on merkitystä, kun kaksi tiedostoa ovat eri mieltä portista, laitteesta tai salauksesta.

Tulosta ensin tehokas kutsu ja katso sitten direktiivejä, jotka määräävät identiteetin ja tavoitettavuuden. Molemmat komennot ovat vain luku -komentoja ja turvallisia käynnissä olevalla palvelimella, vaikka toinen tulostaa polkuja, joita et ehkä halua julkiseen tikettiin.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Tiedosto .ovpn kotihakemistossa on asiakkaan artefakti. Palvelindemoni ei koskaan lue sitä, joten tuon tiedoston muokkaaminen palvelinpuolen kättelyvian korjaamiseksi ei saavuta mitään.

Sisällytykset ovat toinen ansa. Rivi config vetää mukaan toisen tiedoston, jonka valinnat käsitellään siinä kohdassa, joten myöhempi yhden arvon direktiivi voi ohittaa sen, mitä päätiedosto näyttää sanovan. Jos näkyvä tiedosto näyttää oikealta ja demoni käyttäytyy silti eri tavalla, lue sisällytetty tiedosto ennen kuin muutat mitään.

Sovita loki prosessiin, ei virheeseen jonka muistat

Kaksi lokikohdetta on tavallisia, ja vain toinen niistä on journal. Kun log-append on asetettu, demoni kirjoittaa tuohon tiedostoon ja journal säilyttää vähän käynnistysrivien lisäksi. Ilman sitä journalctl on tapahtumien lähde.

journalctl -u openvpn-server@server -n 80 --no-pager

Yhdistä yksi yhteysyritys yhteen aikaikkunaan. Merkitse asiakkaan päätepiste ja lue sitten palvelimen tapahtumat samoista sekunneista. TLS-kättely, joka ei koskaan saavuta varmenteiden vaihtoa, viittaa tavoitettavuuteen tai protokollan eroavuuteen, kun taas todennuksen hylkäys saapuu vasta, kun tunnelin parametrit on jo sovittu.

Vanha lokimerkintä ei todista mitään profiilista, jonka latasit viisi minuuttia sitten. Luo asiakastiedosto uudelleen, yhdistä kerran ja lue vain ne rivit, jotka ilmestyivät kyseisen yrityksen aikana.

Kirjaa ensimmäinen konkreettinen vika, älä viimeistä yleistä. Sidontavirhe, vastaamaton ulkoinen vaihto, varmenteen hylkäys ja tilin hylkäys vievät kukin eri kerrokseen, ja lopun aikakatkaisu usein kätkee hyödyllisen tapahtuman sen yläpuolella.

Tunnelin uudelleenrakentaminen ei ole diagnostiikkavaihe

Houkkutteleva oikotie on pystyttää toinen, yksinkertaisempi tunneli: staattinen avain, ei varmenteita, ei lisätodennusta. Se yhdistää usein, ja se todistaa vain, että kaksi isäntää voi välittää UDP:tä tai TCP:tä välillään. Se ei kerro mitään siitä, miksi varmenteilla todennettu käyttöönotto epäonnistuu, ja se korvaa hiljaisesti sen turvamallin, joka sinun piti pitää.

Sama koskee tls-auth tai tls-crypt poistamista käytöstä, verify-x509-name löysentämistä tai toisen tekijän pudottamista vihreän tilan saamiseksi. Tunneli, joka yhdistyy siksi, että varmennus poistettiin, on eri järjestelmä, ei korjattu.

Tee yksi rajattu muutos siinä kerroksessa, jonka loki nimesi, käynnistä sama yksikkö uudelleen ja toista yksittäinen yhteysyritys. Se pitää vertailun rehellisenä ja jättää muutoksen, jonka voit perua.

Mitä antaa seuraavalle henkilölle

Kirjoita neljä tosiasiaa muistiin, kun sinulla vielä on ne: OpenVPN-versio openvpn --version, aktiivinen yksikkö, määritysketju sisällytyksineen ja loki-ikkuna, joka kattaa yhden yrityksen. Ne neljä muuttavat epämääräisen valituksen toistettavaksi tapaukseksi.

Poista arkaluontoiset tiedot ennen jakamista. Yksityiset avaimet, auth-user-pass ja muut tiedostot, staattisen avaimen materiaali ja täydelliset asiakaspaketit eivät kuulu tikettiin; valintojen nimet ja ketjun muoto riittävät yleensä toiselle silmäparille.

Jos ketju on ehjä ja loki osoittaa edelleen verkkoon, seuraava vaihe on polku asiakkaan ja palvelimen välillä eikä uusi asennus. Se on ainoa osa tarinaa, jota avustaja ei koskaan omistanut.