OpenVPN-palvelu pysähtyy yksityisen avaimen salasanakyselyyn: näin korjaat sen
Palvelulla ei ole päätettä, joten salattu avain tarvitsee askpassin ja luettavan tiedoston. Erota avaimen salalause palvelimen kirjautumisesta ja tarkista unit.
OpenVPN kysyy yksityisen avaimen salalausetta paikallisella koneella, joten toimiva kirjautumistiedosto ei koskaan vastaa siihen. Palvelussa ei ole päätettä kirjoittamiseen, ja käynnistys joko jumittuu tai epäonnistuu journal-merkinnällä, joka nimeää syötteen eikä syytä. Mukana on kaksi salaisuutta, ja kumpikin tarvitsee oman luettavan lähteensä ennen unitin uudelleenkäynnistystä. Alla oleva kulku erottaa ne ja tarkistaa sitten identiteetin, joka todella avaa kunkin tiedoston.
Erota kaksi kyselyä
Avaimen salalause purkaa paikallisen yksityisen avaimen salauksen; tilin tunnukset todentavat istunnon palvelimelle. Ne tulevat eri paikoista, epäonnistuvat eri hetkinä ja antavat eri viestejä. Niiden sekoittaminen lähettää ihmiset etsimään salasanan nollausta, vaikka tili ei ollut lainkaan mukana. Lue kyselyn teksti ennen minkään valinnan muuttamista, sillä sanamuoto on ainoa luotettava vihje siitä, mikä salaisuus puuttuu.
Community OpenVPN 2.x:ssä askpass nimeää tiedoston, joka pitää avaimen salalauseen ensimmäisellä rivillään, ja auth-user-pass tiedoston, jossa käyttäjänimi on yhdellä rivillä ja salasana seuraavalla. Kumpikaan tiedosto ei täytä toista valintaa. Työpöytäsovellus tai NetworkManager-profiili voi pitää molempia omassa salaisuussäilössään, jota komentoriviasiakas ei koskaan lue, joten merkitse muistiin, mitä asiakasta olet konfiguroimassa ennen minkään polun kirjoittamista.
Ohjaa molemmat valinnat luettaviin tiedostoihin
Profiili, joka tarvitsee molemmat syötteet, päätyy kolmeen tiedostoviittaukseen: salattu avain, sen avaava salalause ja kirjautumispari. Lisää ne koskematta CA:han tai identiteettitarkistuksiin, sillä ne päättävät, kuka palvelin on, eivätkä kuulu tähän ongelmaan. Jos käyttöönotto ei käytä tilitunnuksia lainkaan, auth-user-pass luo syötteen, jota kukaan ei voi toimittaa.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authPaljaat valinnat käyttäytyvät eri tavoin kuin polulliset valinnat, ja palvelussa ero on merkittävä. askpass ilman argumenttia lukee yhä konsolia, ja vain käyttäjänimen sisältävä auth-user-pass-tiedosto jättää yhä salasanakyselyn odottamaan. Kun asiakas siirtyy taustapalveluksi, se ei voi lainkaan pyytää syötettä päätteeltä, joten näin konfiguroitu palvelu ei nouse.
Absoluuttiset polut poistavat työhakemistokysymyksen mutta eivät anna pääsyä. Seuraavaksi tulevat omistajuus, tila ja läpäisy, ja kaikki kolme tarkistetaan sitä tiliä vasten, jonka alla prosessi toimii.
Lue unitin kokoonpano ennen profiilia
Sen, minkä kokoonpanon instanssi lataa, päättää unit eikä tiedosto, jota olit muokkaamassa. Lue sen komentorivi ja kaikki drop-init ja seuraa sitten työhakemistoa profiiliin, jota todella käytetään. Toiseen .ovpn-tiedostoon lisätty salalauseviittaus ei muuta tälle instanssille mitään.
Kolme vain luku -komentoa vastaavat suurimpaan osaan. Ensimmäinen tulostaa unitin ja kaikki drop-init, toinen identiteetin ja prosessia sitovat sandbox-asetukset, ja kolmas sen, mistä viime käynnistys todella valitti. Käytä instanssin nimeä, joka isännässä on:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bKiinnitä huomiota ProtectHome-asetukseen ja profiilin omiin valintoihin user, group ja chroot. Kotihakemiston alla oleva tiedosto voi olla kuoressasi luettava ja palvelun sisällä näkymätön, kun kotihakemistot piilotetaan. Tili, jolla systemd käynnistyy, ei aina ole se tili, joka lopulta avaa avaimen.
Todista, että ajonaikainen identiteetti voi avata molemmat tiedostot
Tilan lukeminen ei riitä, koska jokaisen polun hakemiston on oltava saman identiteetin läpäistävissä. Käy polku läpi komponentti kerrallaan ja testaa sitten avaaminen sillä tilillä, jota prosessi käyttää. Tiedosto, jonka tila on 600 ja omistaja root, toimii vain niin kauan kuin prosessi on vielä root, mikä ei pidä paikkaansa monien profiilien tekemän oikeuksien laskun jälkeen. Kaksi komentoa kattavat läpäisyn ja avaamisen:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableEnsimmäinen komento tulostaa kunkin komponentin tilan ja epäonnistuu siellä, missä tili ei voi läpäistä; toinen vastaa ainoaan tärkeään kysymykseen eli siihen, voiko ajonaikainen identiteetti avata tiedoston lukemista varten. Kumpikaan ei tulosta tiedoston sisältöä, ja juuri se on tarkoitus, kun tiedostossa on salalause. Toista testi kirjautumistiedostolle, sillä ne kaksi säilytetään usein eri omistuksella.
Jos prosessi käyttää chrootia tai rajoitettua namespacea, aja sama testi kyseisen näkymän sisältä, muuten vastaus kuvaa väärää tiedostojärjestelmää. Piilotetun kotihakemiston alle tallennettu salalause on tavallinen esimerkki testistä, joka menee läpi unitin ulkopuolella ja epäonnistuu sen sisällä.
Tarkista ensimmäinen käynnistys ja sitten uudelleenyhdistäminen
Käynnistä instanssi kerran ja lue ensimmäinen eikä viimeinen virhe. Puuttuva syötetiedosto, epäonnistunut avaimen purku ja palvelimen AUTH_FAILED ovat kolme eri tapahtumaa, joilla on kolme eri korjausta. Käyttöoikeusvaroituksen korjaaminen ei todista mitään siitä, avattiinko avain.
Journal-rivi kertoo, mikä kolmesta tapauksesta sinulla on. Korjaus seuraa siitä, mikä syöte epäonnistui:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Testaa sitten elinkaari, jota todella tarvitset: käynnistys bootissa ja kaikki tuetut uudelleenyhdistämiset, ei vain manuaalinen käynnistys kuorestasi. Kun auth-nocache on käytössä, syötteet hylätään ensimmäisen käytön jälkeen, joten myöhempi uudelleenyhdistäminen tarvitsee yhä luettavan lähteen. Työpöytäkirjautumisessa avattava avainnippu ei ole sellaisen palvelun käytettävissä, joka käynnistyi ennen kuin kukaan kirjautui sisään, ja se on tavallinen syy siihen, että manuaalinen testi menee läpi ja uudelleenkäynnistys epäonnistuu. Jos ensimmäinen käynnistys onnistuu ja myöhempi uudelleenyhdistäminen epäonnistuu, lue journalista uudelleenyhdistämistapahtuma ennen kuin muutat oikeuksia uudelleen.
Salalauseen tallentaminen avaimen viereen vähentää sitä, mitä salaus sinulle antaa, joten rajoita sitä tiedostoa ja sen varmuuskopioita. Avaimen salalauseen poistaminen on erillinen tunnusten päätös, ei puuttuvan syötteen korjaus. Käyttöönotto, joka riippuu ihmisen hyväksynnästä tai interaktiivisesta MFA:sta, tarvitsee tuetun agentin tai hallintaintegraation; pysyvästi tallennettu kertakäyttökoodi ei ole vastaava korvike.