openvpn3 session-start ignorerar din inloggningsfil
3.x-klienten tar inloggningsuppgifter när sessionen startar och läser inte en sparad fil. Använd prompten eller autoload-vägen, och vet vad var och en lagrar.
Anslut med 2.x-klienten och profilen fungerar; ge samma fil till 3.x-klienten och den stannar vid en lösenordsprompt. Ge --auth-user-pass creds.txt till openvpn3 session-start och resultatet är detsamma, eftersom den nyare klienten inte har något steg som läser filen. Avslaget är avsiktligt: inloggningsuppgifter tillhör en session, och en session skapas av en tjänst, inte av processen i din terminal. Välj mellan den interaktiva prompten och autoload-hjälparen, och vet vad var och en lagrar.
Varför den sparade filen inte har någonstans att ta vägen
I den nyare designen är konfigurationshantering och sessionshantering separata tjänster som talar över systembussen. Det är den separationen som låter en vanlig användare starta en session utan att en privilegierad daemon läser en skyddad lösenordsfil för deras räkning. Filbaserade inloggningsuppgifter har ingen plats i den modellen, eftersom det inte finns någon uppstart på daemonsidan som skulle läsa dem. Avslaget är en konsekvens av arkitekturen, inte en saknad funktion.
Det gamla mönstret är värt att namnge så att det är lättare att avlära sig: en profil refererar till en inloggningsfil och daemonen läser den när tunneln startar. I den nya modellen tillhör inloggningsuppgifterna en session och levereras när den sessionen börjar. openvpn3 session-start --config work.ovpn frågar efter dem, och --auth-user-pass creds.txt avvisas eftersom ingenting på den vägen skulle öppna filen. Varje 2.x-recept du hittar förutsätter ett steg som inte längre finns.
Konfiguration och lokala webbplatsinställningar är också separerade, vilket förklarar en andra överraskning. En profil kan se komplett ut medan anslutningen den producerar saknar routing- och resolverkonfiguration. De delarna tillämpas som lokala inställningar, separat från den importerade filen.
Promptvägen och sessionen den lämnar efter sig
Att ange lösenordet när sessionen startar är det avsedda arbetsflödet. Klienten frågar en gång, lämnar inloggningsuppgifterna till sessionens backend och fortsätter:
openvpn3 session-start --config work.ovpn
openvpn3 sessions-list
På den vägen skrivs ingenting till disk. Sessionen fortsätter också att köra efter att terminalen stängs, vilket förvånar dem som förväntar sig att processen ska dö med skalet. Det är poängen med att flytta sessionshanteringen till en tjänst. Sessionen överlever terminalen som bad om den, och den måste stoppas explicit.
För en arbetsstation med en människa framför är detta också det säkraste alternativet, eftersom det inte finns någon lagrad hemlighet att skydda eller glömma. Det är bara olämpligt där ingen är på plats för att skriva.
Automatisering utan en person vid tangentbordet
Där en maskin måste ansluta utan en person tillhandahåller projektet openvpn3-autoload. Den läser en katalog med profiler och en matchande beskrivning per profil, och beskrivningen anger inloggningsuppgifterna i klartext. Hjälparen är en separat binärfil, vanligtvis på /usr/sbin/openvpn3-autoload, inte en flagga på session-start. Att ställa in den innebär att skapa katalogen, kopiera profilen under namnet beskrivningen förväntar sig och skriva beskrivningen.
En inställning per användare ser ut så här, körd som kontot som kommer att äga sessionen. Katalogläget håller andra lokala användare ute:
mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload
Beskrivningen namnger inloggningsuppgifterna och begär automatisk start. Håll lösenordsvärdet utanför versionskontrollen:
{
"autostart": true,
"user-auth": {
"autologin": true,
"username": "svc-vpn",
"password": "change-this-value"
}
}
Anropa sedan hjälparen en gång och bekräfta att sessionen dyker upp. Det andra kommandot är kontrollen, inte ett till installationssteg:
/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list
Vid uppstart använder en paketerad enhet som heter openvpn3-autoload.service den systemomfattande katalogen /etc/openvpn3/autoload, inte den per användare. Den platsen kräver root-ägande och ett striktare läge, och beskrivningen håller fortfarande lösenordet i klartext. Avvägningen är explicit: lösenordet ligger nu på disk, så behandla katalogen som en hemlighet, uteslut den från säkerhetskopior utanför värden och välj den interaktiva vägen varje gång en person är närvarande.
Bussfel som ser ut som lösenordsfel
Vissa fel som tillskrivs inloggningsuppgifterna är inget sådant. Ett behörighetsfel som namnger tjänstens aktiveringsväg betyder en av två saker: backend är inte igång, eller anroparen saknar behörighet att aktivera den. Ingen profilredigering ändrar något av dem. Kontrollera tjänstens status och den medföljande busspolicyn innan du rör konfigurationen.
Kommandona nedan skiljer de två. Den första rapporterar om backend är igång; den andra visar nyliga bussfel:
systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20
Den andra vanliga felläsningen är en session som dyker upp och sedan försvinner direkt. Det mönstret betyder oftast att de lokala inställningarna aldrig tillämpades, så tunneln kom upp utan de rutter och resolverändringar som gör den användbar. Läs sekvensen och inte den sista raden: om sessionen skapades, om den nådde ett anslutet tillstånd och om den överlevde är tre separata fakta.
När den äldre klienten fortfarande används
2.x-klienten accepterar fortfarande en inloggningsfil, och en nyckelring kan svara på dess prompt utan att hemligheten någonsin når disken. En wrapper löser upp posten, så filen namnger sökningen i stället för lösenordet. Detta arrangemang beror på en upplåst nyckelring, vilket en container utan inloggningssession eller en enhet som startar innan någon loggar in inte kan tillhandahålla. Sökverktyget rapporterar då en samling det inte kan skriva till, så felet ser ut som ett inloggningsfel när det är ett nyckelringsfel.
Innan du bygger något av detta, kontrollera om en keepalive-inställning i profilen tar bort behovet av omstart helt. En session som stannar uppe når aldrig prompten du försöker automatisera.