OpenVPN Access Server: rinis daemonin apo zbato konfigurimin
systemctl restart openvpnas rinis daemonin; sacli start ngre shërbimet e brendshme. Ndiqni atë që thotë dokumentacioni i konfigurimit dhe më pas verifikoni më shumë se active.
Dy komanda ngjiten për atë që duket si e njëjta punë në OpenVPN Access Server, dhe ato bëjnë gjëra të ndryshme. systemctl restart openvpnas ndalon dhe nis të gjithë produktin. sacli start ngre shërbimet e brendshme që lexojnë konfigurimin që sapo ndryshuat. Zgjedhja midis tyre nuk është çështje shije: varet nga ajo që thotë dokumentacioni i vetë konfigurimit, nëse sesioni juaj kalon përmes serverit që do të rinisni dhe nëse po shikoni produktin e duhur.
Dy shtresa, një daemon
Access Server funksionon si një njësi e vetme systemd, openvpnas, dhe ai daemon mbikëqyr shërbimet e brendshme pas ndërfaqes web dhe dëgjuesit e VPN. sacli është ndërfaqja e linjës së komandës për të njëjtin instalim, në /usr/local/openvpn_as/scripts/sacli, dhe mund të nisë, ndalojë dhe pyesë ato komponentë të brendshëm pa zëvendësuar njësinë.
Prandaj ekzistojnë të dyja komandat. Rinisja e daemonit ekzekuton gjithçka nga e para, përfshirë procesin që përfundon tunelet e klientëve. sacli start i kërkon daemonit që tashmë punon të ngrejë komponentët e tij që të lexojnë konfigurimin e ri, dhe kjo është ajo që kërkojnë në të vërtetë shumica e ndryshimeve të vetive.
Kushti i parë: çfarë thotë dokumentacioni i konfigurimit
Lexoni faqen e konfigurimit që ndryshuat, jo të një konfigurimi që ndryshuat muajin e kaluar. Pas një vetie të shkruar përmes ConfigPut zakonisht vjen sacli start, dhe ai çift është hapi i dokumentuar i zbatimit. Një ndryshim në sjelljen në nivel dëgjuesi, ose çdo gjë që faqja e përshkruan si kërkim rinisjeje të shërbimit, është klasa ku rinisja e njësisë është e saktë.
Dy komandat nuk janë të këmbyeshme, prandaj mënyra e dështimit kur hamendësoni është asimetrike. Përdorimi i sacli start kur duhej një rinisje e plotë lë një proces të vjetër që vazhdon të shërbejë konfigurimin e mëparshëm, dhe kjo duket sikur konfigurimi u injorua. Një rinisje e plotë kur mjaftonte sacli start nxjerr jashtë çdo klient të lidhur pa arsye.
Kushti i dytë: a është sesioni juaj brenda tunelit
Nëse e administroni Access Server përmes VPN-së që ofron, rinisja heq lidhjen që mbart shell-in tuaj. Komanda mund të përfundojë pasi sesioni juaj vdes, kështu që hamendësoni nëse funksionoi. Për të njëjtën arsye sacli start mund të ndërpresë shkurt një sesion kur komponenti që riniset trajton trafikun tuaj.
Mbani një rrugë jashtë brezit të hapur përpara secilës komandë: një konsolë e ofruesit, një konsolë e hipervizorit ose një sesion serial. Ky kusht vendos kur e ekzekutoni komandën, jo cilën, dhe është ai që e kthen një ndryshim dy minutash në raport ndërprerjeje.
Kushti i tretë: a është ky produkti që mendoni
Access Server nuk është Community OpenVPN. Një instalim community ekzekuton njësi si openvpn@server ose openvpn-client@profile, me konfigurimin në /etc/openvpn, dhe sacli nuk ekziston atje. Rinisja e çdo njësie me openvpn në emër në një host të përbashkët është mënyra se si tunelet e palidhura bien së bashku.
Identifikoni përpara se të prekni çdo gjë: systemctl status openvpnas --no-pager përgjigjet nëse Access Server është ai që punon, sacli status liston komponentët e tij të brendshëm, dhe systemctl list-units --type=service liston njësitë emrat e të cilave përmbajnë openvpn. Nëse komanda e fundit tregon njësi me emra profili, jeni në produktin community dhe pjesa tjetër këtu nuk ju vlen.
Zbatojeni, pastaj verifikoni përtej active
Një njësi që raporton active ka një proces që punon, gjë që nuk është njësoj si një rrugë vërtetimi që funksionon. Pas hapit të zbatimit, kontrolloni sacli status për komponentët që prisnit të rinisnin, konfirmoni që vlera u ruajt me sacli ConfigQuery, dhe më pas ekzekutoni një hyrje klienti të kufizuar me një llogari testuese.
Përfundoni me diçka në nivel aplikacioni: arrini një burim privat përmes tunelit, jo vetëm një ping drejt adresës publike të serverit. Një shtrëngim duarsh që ka sukses ndërsa rruga e shtyrë ose konfigurimi i DNS-së janë të gabuar do të kalojë çdo kontroll shërbimi dhe prapë do të zhgënjejë personin që raportoi problemin.
tutoriali i ofruesit për menaxhimin e shërbimeve është referenca për atë se cilat operacione i përkasin sacli, dhe ia vlen ta hapni përpara se të vendosni që rinisja është opsioni i sigurt.
Vendimi në një kalim
Kalon nëpër këto katër rreshta dhe ndaloni në të parin që përputhet:
- Faqja e konfigurimit përmend sacli start, ose sapo ekzekutuat ConfigPut: përdorni sacli start.
- Faqja kërkon rinisje, ose ndryshimi prek dëgjuesit dhe jo vetitë: përdorni systemctl restart openvpnas.
- Shell-i juaj vjen përmes këtij serveri: organizoni fillimisht aksesin në konsolë, pastaj ekzekutoni komandën që zgjodhën dy rreshtat më sipër.
- Verifikim: sacli status, ConfigQuery për vlerën, një hyrje, një burim privat. Vetëm gjendja e shërbimit nuk është vija e finishit.
Dy nga ato rreshta janë kontrolle dhe dy janë veprime, dhe ky është kuptimi i rendit. Nëse nuk mund t i përgjigjeni pyetjes për produktin, ndaloni: komanda që do të ekzekutonit i përket një instalimi tjetër, dhe tuneli që do të rrëzoni nuk do të jetë ai që kishit ndërmend.