openvpn3 session-start negeert je inloggegevensbestand

Verbind met de 2.x-client en het profiel werkt; geef hetzelfde bestand aan de 3.x-client en hij stopt bij een wachtwoordprompt. Geef --auth-user-pass creds.txt aan openvpn3 session-start en het resultaat is hetzelfde, omdat de nieuwere client geen fase heeft die het bestand leest. De weigering is bewust: inloggegevens horen bij een sessie, en een sessie wordt gemaakt door een dienst, niet door het proces in je terminal. Kies tussen de interactieve prompt en de autoload-helper, en weet wat elk opslaat.

Waarom het opgeslagen bestand nergens heen kan

In het nieuwere ontwerp zijn configuratiebeheer en sessiebeheer aparte diensten die over de systeembus praten. Die scheiding is wat een gewone gebruiker in staat stelt een sessie te starten zonder dat een bevoorrechte daemon namens hem een beveiligd wachtwoordbestand leest. Op bestanden gebaseerde inloggegevens hebben geen plaats in dat model, omdat er geen opstart aan de daemon-kant is die ze zou lezen. De weigering is een gevolg van de architectuur, geen ontbrekende functie.

Het oude patroon is het benoemen waard zodat het makkelijker af te leren is: een profiel verwijst naar een inloggegevensbestand en de daemon leest het wanneer de tunnel start. In het nieuwe model horen inloggegevens bij een sessie en worden ze geleverd wanneer die sessie begint. openvpn3 session-start --config work.ovpn vraagt erom, en --auth-user-pass creds.txt wordt geweigerd omdat niets op dat pad het bestand zou openen. Elk 2.x-recept dat je vindt gaat uit van een fase die niet meer bestaat.

Configuratie en site-lokale instellingen zijn ook gescheiden, wat een tweede verrassing verklaart. Een profiel kan compleet lijken terwijl de verbinding die het oplevert routing- en resolverconfiguratie mist. Die onderdelen worden toegepast als site-lokale instellingen, los van het geïmporteerde bestand.

Het promptpad en de sessie die het achterlaat

Het wachtwoord opgeven wanneer de sessie begint is de bedoelde werkwijze. De client vraagt één keer, geeft de inloggegevens aan de sessiebackend en gaat verder:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Via dat pad wordt niets naar schijf geschreven. De sessie blijft ook draaien nadat de terminal sluit, wat mensen verrast die verwachten dat het proces met hun shell sterft. Dat is het punt van sessieafhandeling naar een dienst verplaatsen. De sessie overleeft de terminal die erom vroeg, en ze moet expliciet worden gestopt.

Voor een werkstation met een mens ervoor is dit ook de veiligste optie, omdat er geen opgeslagen geheim is om te beschermen of te vergeten. Het is alleen ongeschikt waar niemand aanwezig is om te typen.

Automatisering zonder iemand achter het toetsenbord

Waar een machine moet verbinden zonder een mens, levert het project openvpn3-autoload. Het leest een map met profielen en een bijpassende descriptor per profiel, en de descriptor levert de inloggegevens in platte tekst. De helper is een apart binair bestand, meestal op /usr/sbin/openvpn3-autoload, geen vlag op session-start. Hem instellen betekent de map aanmaken, het profiel kopiëren onder de naam die de descriptor verwacht, en de descriptor schrijven.

Een instelling per gebruiker ziet er zo uit, uitgevoerd als het account dat de sessie zal bezitten. De mapmodus houdt andere lokale gebruikers buiten:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

De descriptor benoemt de inloggegevens en vraagt om automatisch starten. Houd de wachtwoordwaarde buiten versiebeheer:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Roep dan de helper één keer aan en bevestig dat de sessie verschijnt. De tweede opdracht is de controle, geen extra installatiestap:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Bij het opstarten gebruikt een verpakte unit met de naam openvpn3-autoload.service de systeembrede map /etc/openvpn3/autoload, niet die per gebruiker. Die locatie vereist root-eigendom en een strakkere modus, en de descriptor houdt het wachtwoord nog steeds in platte tekst. De afweging is expliciet: het wachtwoord staat nu op schijf, dus behandel die map als een geheim, sluit hem uit van back-ups buiten de host, en kies het interactieve pad wanneer er een persoon aanwezig is.

Busfouten die op wachtwoordfouten lijken

Sommige fouten die aan inloggegevens worden toegeschreven zijn dat helemaal niet. Een permissiefout die het activeringspad van de dienst noemt betekent een van twee dingen: de backend draait niet, of de aanroeper mist de permissie om hem te activeren. Geen profielbewerking zal een van beide veranderen. Controleer de dienststatus en het meegeleverde busbeleid voordat je de configuratie aanraakt.

De onderstaande opdrachten scheiden de twee. De eerste meldt of de backend draait; de tweede toont recente busfouten:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

De andere veelvoorkomende verkeerde lezing is een sessie die verschijnt en meteen weer verdwijnt. Dat patroon betekent meestal dat de site-lokale instellingen nooit zijn toegepast, zodat de tunnel omhoogkwam zonder de routes en resolverwijzigingen die hem nuttig maken. Lees de volgorde en niet de laatste regel: of de sessie is gemaakt, of ze een verbonden status bereikte en of ze overleefde zijn drie afzonderlijke feiten.

Wanneer de oudere client nog in gebruik is

De 2.x-client accepteert nog steeds een inloggegevensbestand, en een keyring kan op zijn prompt antwoorden zonder dat het geheim ooit de schijf raakt. Een wrapper lost de vermelding op, zodat het bestand de opzoeking noemt in plaats van het wachtwoord. Deze opzet hangt af van een ontgrendelde keyring, die een container zonder inlogsessie of een unit die start voordat iemand inlogt niet kan bieden. Het zoekhulpmiddel meldt dan een verzameling waarin het niet kan schrijven, dus de fout lijkt een inloggegevensfout terwijl het een keyringfout is.

Voordat je hier iets van bouwt, controleer of een keepalive-instelling in het profiel de noodzaak om te herstarten helemaal wegneemt. Een sessie die blijft staan bereikt nooit de prompt die je probeert te automatiseren.