openvpn3 session-start nepaiso jūsų prisijungimo duomenų failo

Prisijunkite su 2.x klientu ir profilis veikia; perduokite tą patį failą 3.x klientui ir jis sustoja ties slaptažodžio raginimu. Perduokite --auth-user-pass creds.txt komandai openvpn3 session-start ir rezultatas tas pats, nes naujesnis klientas neturi etapo, kuris skaitytų failą. Atsisakymas yra tyčinis: prisijungimo duomenys priklauso sesijai, o sesiją sukuria paslauga, o ne procesas jūsų terminale. Pasirinkite tarp interaktyvaus raginimo ir autoload pagalbininko ir žinokite, ką kiekvienas saugo.

Kodėl išsaugotas failas neturi kur dėtis

Naujojoje architektūroje konfigūracijos valdymas ir sesijų valdymas yra atskiros paslaugos, kalbančios per sistemos magistralę. Būtent šis atskyrimas leidžia paprastam naudotojui pradėti sesiją, kai privilegijuotas daemonas jo vardu neskaito apsaugoto slaptažodžio failo. Failu pagrįsti prisijungimo duomenys tame modelyje neturi vietos, nes nėra daemono pusės paleidimo, kuris juos skaitytų. Atsisakymas yra architektūros pasekmė, o ne trūkstama funkcija.

Senąjį modelį verta įvardyti, kad būtų lengviau jo atsisakyti: profilis nurodo prisijungimo duomenų failą, o daemonas jį nuskaito tuneliui startuojant. Naujajame modelyje prisijungimo duomenys priklauso sesijai ir pateikiami jai prasidedant. openvpn3 session-start --config work.ovpn jų prašo, o --auth-user-pass creds.txt atmetamas, nes tame kelyje niekas neatidarytų failo. Kiekvienas 2.x receptas, kurį rasite, numato etapą, kurio nebėra.

Konfigūracija ir svetainės vietiniai nustatymai taip pat atskirti, o tai paaiškina antrą netikėtumą. Profilis gali atrodyti išsamus, nors jo sukuriamam ryšiui trūksta maršrutizavimo ir resolverio konfigūracijos. Tos dalys taikomos kaip vietiniai nustatymai, atskirai nuo importuoto failo.

Raginimo kelias ir sesija, kurią jis palieka

Slaptažodžio pateikimas sesijos pradžioje yra numatyta darbo eiga. Klientas paklausia vieną kartą, perduoda prisijungimo duomenis sesijos backendui ir tęsia:

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

Tuo keliu į diską nieko nerašoma. Sesija taip pat veikia toliau, kai terminalas uždaromas, o tai nustebina žmones, kurie tikisi, kad procesas mirs kartu su jų apvalkalu. Būtent todėl sesijų apdorojimas perkeltas į paslaugą. Sesija gyvuoja ilgiau nei ją paprašęs terminalas, ir ją reikia sustabdyti aiškiai.

Darbo stočiai, priešais kurią sėdi žmogus, tai ir saugiausias pasirinkimas, nes nėra saugomo slaptažodžio, kurį reikėtų apsaugoti ar pamiršti. Jis netinkamas tik ten, kur nėra kam įvesti.

Automatizavimas be žmogaus prie klaviatūros

Ten, kur mašina turi prisijungti be žmogaus, projektas siūlo openvpn3-autoload. Jis nuskaito profilių katalogą ir kiekvienam profiliui atitinkantį aprašą, o aprašas pateikia prisijungimo duomenis atviru tekstu. Pagalbininkas yra atskiras dvejetainis failas, paprastai /usr/sbin/openvpn3-autoload, o ne session-start vėliavėlė. Jį įrengti reiškia sukurti katalogą, nukopijuoti profilį tokiu vardu, kokio tikisi aprašas, ir parašyti aprašą.

Vieno naudotojo sąranka atrodo taip, vykdoma paskyra, kuri valdys sesiją. Katalogo režimas neleidžia kitiems vietiniams naudotojams:

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

Aprašas įvardija prisijungimo duomenis ir prašo automatinio paleidimo. Slaptažodžio vertę laikykite už versijų kontrolės ribų:

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

Tada vieną kartą iškvieskite pagalbininką ir patvirtinkite, kad sesija atsiranda. Antroji komanda yra patikra, o ne dar vienas sąrankos žingsnis:

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

Įkrovimo metu supakuotas įrenginys, vardu openvpn3-autoload.service, naudoja visos sistemos katalogą /etc/openvpn3/autoload, o ne tą, kuris skirtas naudotojui. Tai vietai reikia root nuosavybės ir griežtesnio režimo, o aprašas vis dar laiko slaptažodį atviru tekstu. Kompromisas aiškus: slaptažodis dabar guli diske, todėl traktuokite tą katalogą kaip paslaptį, išskirkite jį iš ne hosto atsarginių kopijų ir visada, kai yra žmogus, rinkitės interaktyvų kelią.

Magistralės gedimai, kurie atrodo kaip slaptažodžio gedimai

Kai kurie gedimai, priskiriami prisijungimo duomenims, visai ne tokie. Leidimų klaida, įvardijanti paslaugos aktyvavimo kelią, reiškia vieną iš dviejų: backendas neveikia arba kvietėjas neturi leidimo jo aktyvuoti. Joks profilio keitimas nepakeis nė vieno. Prieš liesdami konfigūraciją patikrinkite paslaugos būseną ir pateiktą magistralės politiką.

Toliau pateiktos komandos atskiria šiuos du. Pirmoji praneša, ar backendas veikia; antroji rodo naujausias magistralės klaidas:

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

Kitas dažnas neteisingas skaitymas yra sesija, kuri atsiranda ir tuoj pat dingsta. Toks modelis paprastai reiškia, kad vietiniai nustatymai niekada nebuvo pritaikyti, todėl tunelis pakilo be maršrutų ir resolverio pakeitimų, kurie daro jį naudingą. Skaitykite seką, o ne paskutinę eilutę: ar sesija buvo sukurta, ar pasiekė prijungtą būseną ir ar išgyveno, yra trys atskiri faktai.

Kai senesnis klientas dar naudojamas

2.x klientas vis dar priima prisijungimo duomenų failą, o raktų saugykla gali atsakyti į jo raginimą, kai paslaptis niekada nepatenka į diską. Apvalkalas išsprendžia įrašą, todėl failas įvardija paiešką, o ne slaptažodį. Ši sąranka priklauso nuo atrakintos raktų saugyklos, kurios negali suteikti konteineris be prisijungimo sesijos ar įrenginys, startuojantis prieš kam nors prisijungiant. Tada paieškos įrankis praneša apie kolekciją, į kurią negali rašyti, todėl klaida atrodo kaip prisijungimo duomenų gedimas, nors tai raktų saugyklos gedimas.

Prieš ką nors statydami, patikrinkite, ar keepalive nustatymas profilyje visiškai pašalina poreikį paleisti iš naujo. Sesija, kuri lieka veikti, niekada nepasiekia raginimo, kurį bandote automatizuoti.