openvpn3 session-start binabalewala ang file ng iyong mga kredensyal

Kumonekta gamit ang 2.x client at gumagana ang profile; ibigay ang parehong file sa 3.x client at humihinto ito sa prompt ng password. Ibigay ang --auth-user-pass creds.txt sa openvpn3 session-start at pareho ang resulta, dahil walang yugto ang mas bagong client na nagbabasa ng file. Sadyang sinasadya ang pagtanggi: pag-aari ng isang session ang mga kredensyal, at isang serbisyo ang gumagawa ng session, hindi ang proseso sa iyong terminal. Pumili sa pagitan ng interactive na prompt at ng autoload helper, at alamin kung ano ang iniimbak ng bawat isa.

Bakit walang mapupuntahan ang naka-save na file

Sa mas bagong disenyo, ang pamamahala ng configuration at pamamahala ng session ay magkahiwalay na serbisyo na nag-uusap sa system bus. Ang paghihiwalay na iyon ang nagpapahintulot sa ordinaryong user na magsimula ng session nang hindi nagbabasa ang isang privileged daemon ng protektadong password file sa kanilang ngalan. Walang lugar sa modelong iyon ang mga kredensyal na nakabatay sa file, dahil walang startup sa panig ng daemon na magbabasa sa mga ito. Ang pagtanggi ay bunga ng arkitektura, hindi kulang na feature.

Sulit pangalanan ang lumang pattern para mas madaling iwan: tumutukoy ang profile sa isang credentials file, at binabasa ito ng daemon kapag nagsimula ang tunnel. Sa bagong modelo, pag-aari ng isang session ang mga kredensyal at ibinibigay kapag nagsimula ang session na iyon. Hinihingi ito ng openvpn3 session-start --config work.ovpn, at tinatanggihan ang --auth-user-pass creds.txt dahil walang magbubukas ng file sa landas na iyon. Bawat 2.x recipe na makikita mo ay nagpapalagay ng yugtong wala na.

Magkahiwalay din ang configuration at ang mga lokal na setting ng site, na nagpapaliwanag ng ikalawang sorpresa. Maaaring mukhang kumpleto ang profile habang kulang ang koneksyong ginagawa nito sa configuration ng routing at resolver. Ang mga bahaging iyon ay inilalapat bilang lokal na setting ng site, hiwalay sa na-import na file.

Ang landas ng prompt at ang session na iniiwan nito

Ang pagbibigay ng password kapag nagsisimula ang session ang nilalayong workflow. Isang beses lang nagtatanong ang client, ibinibigay ang mga kredensyal sa backend ng session, at nagpapatuloy:

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

Walang naisusulat sa disk sa landas na iyon. Patuloy ding tumatakbo ang session pagkatapos isara ang terminal, na nakakagulat sa mga inaasahang mamamatay ang proseso kasama ng kanilang shell. Iyon ang layunin ng paglipat ng paghawak ng session sa isang serbisyo. Nabubuhay ang session nang mas mahaba kaysa sa terminal na humiling nito, at kailangan itong ihinto nang tahasan.

Para sa isang workstation na may taong nasa harap, ito rin ang pinakaligtas na opsyon, dahil walang naka-save na sikretong kailangang protektahan o kalimutan. Hindi lamang ito angkop kung saan walang taong magta-type.

Automation na walang tao sa keyboard

Kung saan kailangang kumonekta ng makina nang walang tao, nagbibigay ang proyekto ng openvpn3-autoload. Binabasa nito ang isang directory ng mga profile at isang tugmang deskriptor para sa bawat profile, at ibinibigay ng deskriptor ang mga kredensyal sa plain text. Ang helper ay isang hiwalay na binary, karaniwang nasa /usr/sbin/openvpn3-autoload, hindi isang flag sa session-start. Ang pag-set up nito ay nangangahulugan ng paggawa ng directory, pagkopya ng profile sa pangalang inaasahan ng deskriptor, at pagsulat ng deskriptor.

Ganito ang setup kada user, na pinapatakbo bilang account na magmamay-ari ng session. Ang mode ng directory ay naglalayo sa ibang lokal na user:

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

Pinangalanan ng deskriptor ang mga kredensyal at humihingi ng awtomatikong pagsisimula. Itago ang halaga ng password sa labas ng version control:

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

Pagkatapos ay tawagin ang helper nang isang beses at tiyakin na lumilitaw ang session. Ang ikalawang utos ay ang pagsusuri, hindi isa pang hakbang ng setup:

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

Sa boot, isang packaged unit na tinatawag na openvpn3-autoload.service ang gumagamit ng system-wide na directory na /etc/openvpn3/autoload, hindi ang kada user. Kailangan ng lokasyong iyon ng root ownership at mas mahigpit na mode, at hawak pa rin ng deskriptor ang password sa plain text. Ang trade-off ay malinaw: nasa disk na ngayon ang password, kaya ituring ang directory na iyon na sikreto, alisin ito sa mga backup sa labas ng host, at piliin ang interactive na landas tuwing may taong naroroon.

Mga bus failure na mukhang password failure

Ang ilang failure na itinuturing na kasalanan ng mga kredensyal ay hindi ganoon. Ang error sa pahintulot na nagpapangalan sa activation path ng serbisyo ay nangangahulugan ng isa sa dalawa: hindi tumatakbo ang backend, o walang pahintulot ang tumatawag para i-activate ito. Walang pag-edit ng profile ang makakapagbago sa alinman. Suriin ang estado ng serbisyo at ang ibinigay na patakaran ng bus bago hawakan ang configuration.

Hinihiwalay ng mga utos sa ibaba ang dalawa. Iniulat ng una kung tumatakbo ang backend; ipinapakita ng ikalawa ang mga kamakailang bus error:

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

Ang isa pang karaniwang maling pagbasa ay isang session na lumilitaw at agad na nawawala. Karaniwang ibig sabihin ng pattern na iyon ay hindi kailanman nailapat ang mga lokal na setting ng site, kaya umangat ang tunnel nang walang mga ruta at pagbabago sa resolver na nagpapaging kapaki-pakinabang nito. Basahin ang pagkakasunod-sunod at hindi ang huling linya: kung nagawa ang session, kung umabot ito sa konektadong estado, at kung nakaligtas ito ay tatlong hiwalay na katotohanan.

Kapag ginagamit pa rin ang lumang client

Tumatanggap pa rin ang 2.x client ng credentials file, at kayang sagutin ng keyring ang prompt nito nang hindi umaabot ang sikreto sa disk. Niresolba ng wrapper ang entry, kaya pinapangalanan ng file ang paghahanap at hindi ang password. Ang kaayusang ito ay nakasalalay sa nakabukas na keyring, na hindi kayang ibigay ng container na walang login session o ng unit na nagsisimula bago mag-sign in ang sinuman. Pagkatapos ay nag-uulat ang lookup tool ng koleksyong hindi nito kayang sulatan, kaya mukhang fault ng kredensyal ang error kung fault pala ito ng keyring.

Bago magtayo ng anuman sa mga ito, suriin kung inaalis nang lubusan ng keepalive setting sa profile ang pangangailangang mag-restart. Ang session na nananatiling nakaangat ay hindi kailanman umaabot sa prompt na sinusubukan mong i-automate.