Kiel sekure restarigi la agordon de VPN-servilo
Restarigo reestigas konatan bonan retan politikon, ne la plej malnovan dosieron, kiun vi povas trovi. Tenadu la revokojn aktualaj kaj administran vojon ekster la tunelo.
Restarigi servilon estas decido pri tio, kiu tavolo malsukcesis, ne ekzerco pri kopiado de dosieroj. Agordo, akreditaĵoj kaj pakaĵaj versioj moviĝas laŭ apartaj horloĝoj, kaj restarigi unu dum la aliaj restas aktualaj produktas gastigan maŝinon, kiu aspektas sana kaj kondutas malkonsekvence. La jena sinsekvo supozas, ke ŝanĝo jam misfunkciis, kaj petas vin reestigi la plej malgrandan koheran staton. Trapasu ĝin laŭorde kaj traktu la kontrolon de aliro ekster la bendo kiel la paŝon, kiun neniu devus preterpasi.
Faru kontrolpunkton, kiun vi vere povas restarigi
Notu la agordon, kiun la servo legas ĉe lanĉo, kune kun la versio, kiu lastatempe analizis ĝin. Dosiero, kiu ŝarĝiĝis pure sub pli malnova eldono, povas esti rifuzita aŭ silente ignorita post ĝisdatigo, do la versio apartenas al la sama noto. Inkluzivu la materialon, al kiun la agordo montras: privatajn ŝlosilojn, sertifikajn vojojn, difinojn de aŭskultantoj kaj la DNS kaj fajroŝirmajn rikordojn, kiuj igas la servon atingebla. Se restarigo bezonus dosieron, kiun vi ne konservis, la kontrolpunkto estas nekompleta.
Nomu la posedanton de ĉiu agordo, dum la sistemo ankoraŭ sanas. Itinero instalita de la provizanta panelo, unu aldonita de la gastiga fajroŝirmo kaj unu puŝita al klientoj estas tri malsamaj objektoj, kaj restarigi la malĝustan lasas la aliajn du en loko. Mallonga tabelo de agordo, posedanto kaj dosiervojo sufiĉas.
Tenu la revokojn aparte de la agordo
Malnova agordo povas silente rekonekti aparaton, kiun vi intence forigis, kio igas reakiron sekureca regreso. Konservu la nunan revokliston kaj la malŝaltitajn kontojn dum vi restarigas la retan politikon, poste reaplikigu ilin antaŭ ol la servo akceptos klientojn.
Traktu la identecan staton kiel propran restarigon kun propraj pruvoj. Sertifikaj revokdosieroj, konta malŝalto kaj MFA-enskribiĝo malofte loĝas en la sama loko kiel la agordo de la demono, kaj agorda restarigo ne tuŝos ilin. Kontrolu unue la nunan staton, por ke vi sciu, kio devas pluvivi. Post la restarigo, konfirmu, ke la forigita identeco ankoraŭ malsukcesas konekti.
Atingu la gastigan maŝinon, kiam la tunelo malsukcesas
Malfermu vojon al la maŝino, kiu ne dependas de la ŝanĝata komponanto. Hipervizora konzolo, administra adreso sur aparta interfaco aŭ seria konzolo ĉiuj taŭgas; SSH-sesio portata tra la tunelo ne. Se la sola eniro estas la VPN, kiun vi baldaŭ restartigos, malbona itinero aŭ fajroŝirma regulo forprenas vian kapablon ĝin korekti. Testu la alternativan vojon antaŭ la ŝanĝo, ne poste. Salutu tra ĝi unufoje, konfirmu, ke sudo funkcias, kaj notu la precizan adreson, kiun vi uzis.
La testo estas simpla: mallevu la tunelon dum vi estas konektita tra la alternativa vojo kaj vidu, ĉu la sesio pluvivas. Se ĝi falas, vi trovis la difekton antaŭ ol ĝi povas izoli vin.
Apliku unu revizion kaj sciu, kiam ĝi ekvalidas
Uzu la dokumentaron de la servo pri reload aŭ restart kaj eltrovu, kiuj direktivoj estas legitaj en kiu momento. Iuj valoroj validas ĉe reload, aliaj nur kiam komenciĝas nova sesio aŭ procezo, do redakti dosieron pruvas nenion pri la kuranta stato. Restarigu unu revizion anstataŭ miksi novan dosieron kun malnova rultempa stato. Se vi dubas, plena restartigo de la servo estas pli facile pripensebla ol parta reload.
Kontrolu la difinon de la unuo antaŭ ol elekti: systemctl show -p ExecReload openvpn@server diras al vi, ĉu entute ekzistas reload-hoko. Poste apliku la revizion kaj legu en la ĵurnalo la unuajn novajn erarojn antaŭ ol ŝanĝi ion alian.
Kontrolu, registru kaj esploru poste
Konektu unu rajtigitan klienton kaj elprovu, por kio la servo utilas: nomrezolvado, rekonekto kaj la aplikaĵo, kiu malsukcesis. Konfirmu, ke la revokita identeco ankoraŭ estas rifuzata. Registru la revizion, kiun vi restarigis, la tempon kaj la kialon, ĉar la sekva operatoro bezonos ĉiujn tri. Restarigo, kiun neniu dokumentis, fariĝas mistero la sekvan fojon, kiam la servo miskondutos.
systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager
Post kiam la servo stabiliĝas, reproduktu la malsukcesan ŝanĝon sur gastiga maŝino aŭ momento, kiun vi povas forĵeti. Tio apartigas malbonan agordon de malbona pako aŭ eksdata sertifiko. Tenu la restarigitan agordon sub versia kontrolo, por ke la sekva kontrolpunkto komenciĝu de konata commit. La senco de la ekzerco estas dokumentita finpunkto, ne daŭra malaltigo.