OpenVPN odottaa systemd:n salasanapyyntöä: pitäisikö vastata?

Päätteelle ilmestyy viesti systemd-tty-ask-password-agent-komponentista, eikä tunneli ole pystyssä. Houkutteleva tulkinta on, että VPN hylkäsi salasanan ja jokin odottaa nyt korjausta. Tarkemmin sanottuna palvelu pyysi systemd:ltä vuorovaikutteista syötettä, eikä pyyntöön ole vielä vastattu. Mikä palvelu kysyi ja mitä salaisuutta se haluaa, ovat kaksi kysymystä, jotka voit ratkaista ennen kuin kirjoitat mitään.

Kaksi ehtoa ratkaisee, kenen pitäisi vastata

Ensimmäinen ehto on, käynnistitkö tämän instanssin tarkoituksella. Pyyntö, joka seuraa tekemääsi toimea, on sinun vastattavasi, ja se, joka ilmestyy ilman vastaavaa toimea, kuuluu jollekin muulle. Toinen on, onko salaisuus tilin todennus vai avaimen suojaus, koska ne elävät eri paikoissa ja kulkevat eri koodipolkuja. Molemmat vastaukset näkyvät lokissa, jos katsot ennen toimimista.

Kun molemmat vastaukset ovat selviä, päätös on yksinkertainen: vastaa palvelun oman tuetun kehotepolun kautta. Kun jompikumpi on epäselvä, oikea siirto on tutkia sen sijaan, että kirjoittaisit salasanan kehotteeseen, jota et voi kohdentaa.

Siinä on koko sääntö, ja se kannattaa sanoa ennen komentoja. Kaikki alla seuraa siitä.

Listaa pyyntö ennen kuin kirjoitat mitään

Agentti voi luetella, mikä on kesken, vastaamatta mihinkään. sudo systemd-tty-ask-password-agent --list tulostaa avoimet pyynnöt, ja tämä tuloste on todiste, jonka tarvitset kehotteen yhdistämiseen yksikköön. Lue se ennen kuin annat tunnistetiedon, ja pidä pyyntöjen kuvaukset poissa jokaisesta julkisesta diagnostiikkaliitoksesta.

Yhdistä listaus aloittamaasi toimintoon ja yksikköön, joka sen omistaa. Jos mikään listassa ei vastaa toimintaasi, näkemäsi kehote kuuluu toiselle palvelulle eikä ole sinun ratkaistavasi. Listan yksikön nimi on ainoa luotettava yhteys kehotteen ja palvelun välillä.

Älä vastaa pyyntöön, jota et voi kohdentaa. Odottamisen hinta on viive, kun taas väärään kehotteeseen vastaamisen hinta on tunnistetieto väärässä paikassa.

Mitä salaisuutta instanssi oikeastaan tarvitsee?

auth-user-pass koskee tilin todennusta VPN-palveluun, ja ilman tunnistetiedostoa dokumentoitu käyttäytyminen on kysyä konsolilta. askpass puolestaan hankkii salalauseen, joka avaa suojatun avainmateriaalin, ja tekee sen ennen kuin prosessi siirtyy taustalle. Ne ovat eri salaisuuksia, joilla on eri elinikä.

Myös tiedostomuodot eroavat. Tilin muoto odottaa käyttäjänimiriviä ja salasanariviä, kun taas avaimen salalause-tiedosto lukee ensimmäisen rivin salasananaan. Tunnistetiedostoreseptin kopioiminen toisesta roolista tuottaa yleensä vielä yhden kehotteen ratkaisun sijaan. Väärän muotoinen tiedosto on huonompi kuin ei tiedostoa lainkaan, koska vika siirtyy paikkaan, jota kukaan ei valvo.

Tarkista, mitä direktiiviä instanssi käyttää, ennen kuin päätät mitä kirjoitat. Direktiivin nimi kertoo, mitä salaisuutta kehote koskee.

Mitä --query tekee, mitä --list ei tee

--query käsittelee jokaisen odottavan pyynnön kutsuvalla päätteellä, mikä on paljon laajempi toimi kuin yhden kehotteen vastaaminen. Se ei ole OpenVPN-valitsin, ja kiireisellä koneella se voi vastata muille yksiköille kuuluviin pyyntöihin. Tarkkailutila on vielä laajempi, koska se jatkaa pyyntöjen käsittelyä niiden saapuessa.

Käytä kapeinta toimivaa mekanismia. Yhdelle palvelulle sen oma kehotetyönkulku on kapeampi kuin globaali agentti, ja se pitää vastauksen sidottuna yksikköön, joka kysyi.

Kertaluonteisen pyynnön muuttaminen valvomattomaksi globaaliksi agentiksi siksi, että ilmoitus ilmestyi kerran, on tapa, jolla tilapäisestä harmista tulee pysyvä suunnitteluratkaisu. Sama varovaisuus koskee salasanailmoitusyksiköiden poistamista käytöstä koko isännässä.

Päätä ja kirjaa sitten valinta

Valvomattomaan käyttöönottoon sopikaa tunnistetietolähde, tiedosto-oikeudet ja uusimisaikataulu yhteyden omistajan kanssa. Vuorovaikutteinen toinen tekijä voi tarvita henkilön tai oman palveluidentiteetin. Kehotteen vaientaminen ei tuota sitä todennusta, ja auth-user-pass-kohdan poistaminen rikkoo vain palvelun, joka sitä tarvitsee.

Tarkastele vuorovaikutuksen jälkeen samaa instanssia sen seuraavan tapahtuman varalta ja testaa yksityinen resurssi. Jos mikään ei ole kesken, palaa instanssin tilaan sen sijaan, että käynnistäisit jokaisen OpenVPN-yksikön isännässä.