Provizi OpenVPN-klienton per etapoj, kiuj haltas ĉe eraro

Provizskriptoj, kiuj raportas eraron kaj daŭrigas, estas pli malbonaj ol skriptoj, kiuj neniam ruliĝas. Klienta agordo tuŝas protektitajn ŝlosilojn, identecon ĉe la enirejo kaj servon, kiu eble jam servas trafikon. Ĉiu el ili bezonas haltokondiĉon, kaj la skripto devas scii, kiun etapon ĝi atingis, kiam ĝi haltis.

Traktu la tuton kiel unu transakcion kun kvin kontrolpunktoj, kaj igu ĉiun kontrolpunkton rifuzi daŭrigi per si mem.

Ĝustigu la enigojn antaŭ ol tuŝi la dosiersistemon

Komencu per eksplicita kontrakto: unu identeco, unu profila fonto, unu celata servoposedanto. Kontrolu, ke la profilo ekzistas, ke la atestilo kaj ŝlosilo al kiuj ĝi referencas estas legeblaj, kaj ke la cela dosierujo apartenas al la atendata pako. Vojo, kiu solviĝas, ne estas pruvo, ke la materialo malantaŭ ĝi estas kompleta.

Rifuzu malplenajn variablojn frue. Neagordita $DEVICE, kiu ekspansiiĝas al nenio, ŝanĝas install -m 400 $KEY /etc/openvpn/client/ en kopion celitan al dosierujo, kaj la malsukceso alvenas poste kiel servo, kiu ne povas legi sian ŝlosilon.

Kunmetu la profilaron en pretiga dosierujo

Unue konstruu la kompletan aron en privata loko: profilo, CA, klienta atestilo, ŝlosilo kaj ĉiu helpilo, kiun la profilo vokas. Kopiu per install -m 400 -o root -g root por ke permesoj estu agorditaj ĉe kreado, ne poste. Poste kontrolu la referencojn ene de la profilo, ĉar relativa linio ca aŭ key solviĝas rilate al la labora dosierujo de la unuo, tuj kiam la servo ekfunkcias. Nenio estu skribata en la aktivan dosierujon ĝis la tuta aro validiĝos.

Registru nekonfidan fingrospuron de tio, kion produktis ĉi tiu rulo, ekzemple sha256sum office.conf konservitan apud versia markilo. Ĝuste tiu ununura valoro ebligas al relanĉo distingi ĝisdatigon de neniofarado.

Anstataŭigu atome kaj konservu la antaŭan aron

Movu la pretigitan aron al sia loko per unu operacio, kie la dosiersistemo permesas, kaj konservu la reviziitan antaŭan aron sub tempstampita nomo. Parta kopio, kiu lasas novan profilon apud malnova ŝlosilo, produktas servon, kiu aŭtentikigas per la malĝusta identeco kaj registras nenion utilan pri la kaŭzo. Se la anstataŭigo ne povas esti atoma, ordigu la movojn tiel, ke la profilo alvenu laste.

Kiam la celo jam ekzistas, eksplicite decidu, ĉu ĉi tiu rulo estas ĝisdatigo, identa relanĉo aŭ konflikto kun la profilo de alia aparato. Silente anstataŭigi profilon, kiu apartenas al alia identeco, estas la maniero, kiel du maŝinoj finas dividi unu atestilon. Anstataŭe rifuzu la rulon kaj nomu la konfliktantan posedanton.

Aktivigu unu posedanton kaj pruvu ĝin

Elektu unu aktivan vojon, aŭ la systemd-instancon aŭ NetworkManager, kaj uzu ĝin konsekvence. Startigi nemanagitan procezon openvpn apud ŝaltita unuo donas du tunelojn, konkurantajn DNS-ĝisdatigojn kaj neniun klaran respondon, kiun el ili celas haltokomando. Post aktivigo kontrolu systemctl is-active openvpn-client@office, poste la itineron al la fora prefikso, poste resolvectl status por la solvilo, kiun instalis la tunelo. Finu atingante unu rimedon, por kiu la tunelo ekzistas.

Rulanta procezo kaj verda pleto-ikono estas faktoj pri la procezo, ne pruvo, ke la identeco kaj la trafikpolitiko postvivis la transdonon.

Relanĉo kaj malmuntado estas apartaj laborfluoj

Dua rulo devus konverĝi al la samaj reviziitaj dosieroj kaj la sama posedanto, ne krei duan konton aŭ duan demonon. Malmuntado estas propra procedo: haltigu la ĝustan posedanton, arkivu aŭ forigu la lokan profilon laŭ politiko, kaj revoku la identecon ĉe la enirejo. Forigo de loka ŝlosildosiero ne revokas kopion, kiu jam forlasis la maŝinon.

Konservu restaŭran vojon, kiu ne dependas de la tunelo, ekzemple konzolan aliron aŭ duan administran itineron. Proviza ŝanĝo, kiu ŝlosas vin ekster la maŝino, estas malsukcesa ŝanĝo eĉ kiam ĉiu etapo raportis sukceson.

La skripto, kiun indas konservi, estas transakcio pri posedo kaj pruvoj. Mallonga listo de privilegiaj kopikomandoj ne estas la sama afero.