Konektiĝu per la 2.x-kliento kaj la profilo funkcias; donu la saman dosieron al la 3.x-kliento kaj ĝi haltas ĉe pasvorta invito. Donu --auth-user-pass creds.txt al openvpn3 session-start kaj la rezulto estas la sama, ĉar la pli nova kliento havas neniun etapon, kiu legas la dosieron. La rifuzo estas intenca: akreditaĵoj apartenas al sesio, kaj sesion kreas servo, ne la procezo en via terminalo. Elektu inter la interaga invito kaj la aŭtomata ŝarga helpanto, kaj sciu, kion ĉiu el ili konservas.

Kial la konservita dosiero havas nenie por iri

En la pli nova dezajno, administrado de agordo kaj administrado de sesioj estas apartaj servoj, kiuj parolas trans la sistema buso. Ĝuste tiu apartigo ebligas al ordinara uzanto komenci sesion sen ke privilegiita demono legu protektitan pasvortan dosieron nome de la uzanto. Dosierbazitaj akreditaĵoj havas neniun lokon en tiu modelo, ĉar ne ekzistas komenco ĉe la demona flanko, kiu legus ilin. La rifuzo estas sekvo de la arkitekturo, ne mankanta trajto.

Indas nomi la malnovan ŝablonon por pli facile mallerni ĝin: profilo referencas akreditaĵan dosieron, kaj la demono legas ĝin kiam la tunelo komenciĝas. En la nova modelo, akreditaĵoj apartenas al sesio kaj estas liverataj kiam tiu sesio komenciĝas. openvpn3 session-start --config work.ovpn demandas ilin, kaj --auth-user-pass creds.txt estas rifuzata ĉar nenio sur tiu vojo malfermus la dosieron. Ĉiu recepto por 2.x, kiun vi trovas, supozas etapon, kiu ne plu ekzistas.

Agordo kaj retejaj lokaj agordoj ankaŭ estas apartigitaj, kio klarigas duan surprizon. Profilo povas aspekti kompleta dum la konekto, kiun ĝi produktas, mankas al enkursiga kaj solvila agordo. Tiuj partoj aplikiĝas kiel retejaj lokaj agordoj, aparte de la importita dosiero.

La vojo de la invito kaj la sesio, kiun ĝi lasas

Liveri la pasvorton kiam la sesio komenciĝas estas la celata laborfluo. La kliento demandas unufoje, transdonas la akreditaĵojn al la sesia fono kaj daŭrigas:

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

Per tiu vojo nenio skribiĝas al la disko. La sesio ankaŭ daŭras post kiam la terminalo fermiĝas, kio surprizas homojn, kiuj atendas, ke la procezo mortu kun ilia ŝelo. Ĝuste tio estas la senco de translokigi sesian administradon en servon. La sesio postvivas la terminalon, kiu petis ĝin, kaj ĝi devas esti haltigita eksplicite.

Por laborstacio kun homo antaŭ ĝi, ĉi tio ankaŭ estas la plej sekura opcio, ĉar ne ekzistas konservita sekreto por protekti aŭ forgesi. Ĝi ne taŭgas nur tie, kie neniu ĉeestas por tajpi.

Aŭtomatigo sen homo ĉe la klavaro

Kie maŝino devas konektiĝi sen homo, la projekto liveras openvpn3-autoload. Ĝi legas dosierujon de profiloj kaj kongruan priskribilon por ĉiu profilo, kaj la priskribilo liveras la akreditaĵojn en ebena teksto. La helpanto estas aparta duuma dosiero, kutime ĉe /usr/sbin/openvpn3-autoload, ne flago de session-start. Agordi ĝin signifas krei la dosierujon, kopii la profilon sub la nomo, kiun la priskribilo atendas, kaj skribi la priskribilon.

Poruzanta agordo aspektas tiel kaj ruliĝas kiel la konto, kiu posedos la sesion. La dosieruja reĝimo tenas aliajn lokajn uzantojn ekstere:

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

La priskribilo nomas la akreditaĵojn kaj petas aŭtomatan komencon. Tenu la pasvortan valoron ekster versiokontrolo:

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

Poste voku la helpanton unufoje kaj konfirmu, ke la sesio aperas. La dua komando estas la kontrolo, ne plia agorda paŝo:

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

Dum la praŝargo, pakaĵa unuo nomita openvpn3-autoload.service uzas la sistemlarĝan dosierujon /etc/openvpn3/autoload, ne la poruzantan. Tiu loko bezonas posedon de root kaj pli striktan reĝimon, kaj la priskribilo ankoraŭ tenas la pasvorton en klara teksto. La kompromiso estas klara: la pasvorto nun sidas sur la disko, do traktu tiun dosierujon kiel sekreton, ekskludu ĝin el savkopioj ekster la gastiganto, kaj elektu la interagan vojon kiam ajn homo ĉeestas.

Busaj paneoj, kiuj aspektas kiel pasvortaj paneoj

Iuj paneoj atribuitaj al akreditaĵoj tute ne estas tiaj. Permesa eraro, kiu nomas la aktivigan vojon de la servo, signifas unu el du aferoj: la fono ne funkcias, aŭ la alvokanto ne rajtas aktivigi ĝin. Neniu profila redakto ŝanĝos ajnan el la du. Kontrolu la servan staton kaj la liveritan busan politikon antaŭ ol tuŝi la agordon.

La subaj komandoj apartigas la du. La unua raportas, ĉu la fono funkcias; la dua montras freŝajn busajn erarojn:

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

La alia ofta mislego estas sesio, kiu aperas kaj tuj malaperas. Tiu ŝablono kutime signifas, ke la retejaj lokaj agordoj neniam estis aplikitaj, do la tunelo leviĝis sen la enkursigaj kaj solvilaj ŝanĝoj, kiuj igas ĝin utila. Legu la sinsekvon anstataŭ la lastan linion: ĉu la sesio estiĝis, ĉu ĝi atingis konektitan staton kaj ĉu ĝi postvivis estas tri apartaj faktoj.

Kiam la pli malnova kliento ankoraŭ uziĝas

La 2.x-kliento ankoraŭ akceptas akreditaĵan dosieron, kaj ŝlosilringo povas respondi al ĝia invito sen ke la sekreto iam atingas la diskon. Ĉirkaŭaĵo solvas la eron, do la dosiero nomas la serĉadon anstataŭ la pasvorton. Ĉi tiu aranĝo dependas de malŝlosita ŝlosilringo, kion ujo sen ensaluta sesio aŭ unuo, kiu komenciĝas antaŭ ol iu ensalutas, ne povas provizi. La serĉilo tiam raportas kolekton, en kiun ĝi ne povas skribi, do la eraro aspektas kiel akreditaĵa paneo, kiam ĝi estas ŝlosilringa paneo.

Antaŭ ol konstrui ion el tio, kontrolu, ĉu keepalive-agordo en la profilo tute forigas la bezonon restartigi. Sesio, kiu restas supre, neniam atingas la inviton, kiun vi provas aŭtomatigi.

Rilataj artikoloj