OpenVPN montras active (exited)? Trovu la instancon, kiun vi lanĉis

Vi kontrolas la tunelon, rulas systemctl status openvpn kaj ricevas active (exited) sen Main PID kaj kun malplena procezlisto. La natura legado estas, ke la servo ekfunkciis kaj mortis, do vi malfermas la uniton, trovas /bin/true kaj konkludas, ke la pako estas difektita. En la Debian-pakado tiu stato estas la ĉirkaŭaĵo laboranta laŭ la dezajno, kaj la tunelo vivas en unu el la instancaj unitoj, kiujn ĝi lanĉas. La agregita unuo neniam diros al vi, kiu instanco konstruis ĝin.

Kion active (exited) vere signifas ĉe ĉi tiu unuo

La paka unuo estas unufoja tasko: ĝia ExecStart estas /bin/true, kaj RemainAfterExit=yes estas tio, kio tenas finitan uniton raportata kiel active (exited). Forigu tiun direktivon kaj la sama sukcesa /bin/true-tasko finiĝas en inactive (dead), kio estas ĝuste la stato, kiun homoj atendas kaj mislegas en la kontraŭa direkto. La komando estas anstataŭilo, kaj la unuo raportas pri laboro, kiun faras aliaj unitoj. Nenio en tiu aranĝo estas difektita, kaj anstataŭigi /bin/true ŝanĝas la pakadan kontrakton, ne la tunelon.

La ĉirkaŭaĵo delegas. Ĝi lanĉas la instancajn unitojn, kiujn provizas la paka konfiguracio aŭ ĝia systemd-generatoro, kaj tial malplena procezlisto pruvas nenion pri la tunelo. Kiam neniu instanco estas elektita, la ĉirkaŭaĵo tamen sukcesas kaj tamen lanĉas nenion. La stato respondas, ĉu la ĉirkaŭaĵo ruliĝis, ne ĉu ekzistas tunelo.

Legu la tri liniojn de la status-eligo anstataŭ la vorton en krampoj. Loaded nomas la unitan dosieron, kiun systemd legis, Active portas la tempostampon de la lasta sukcesa rulado, kaj la forestanta Main PID kongruas kun finita unufoja tasko. Tiuj tri linioj ankaŭ estas kiel distingi ĉi tiun ĉirkaŭaĵon de servo, kiu kraŝis sekundon post la lanĉo.

Listigu la unitojn antaŭ ol relegi la statuson

Demandu systemd, kio ekzistas, antaŭ ol demandi, kio ruliĝas. Ŝablono povas esti instalita dum neniu instanco estas kreita, kaj nur kreita unuo portas tunelon. Komencu per la ŝarĝita aro:

systemctl list-units 'openvpn*'

Tiu listo estas tio, kion systemd ŝarĝis en ĉi tiu momento, kaj ĝi estas la plej proksima afero al tunela inventaro. Instalitaj unitaj dosieroj respondas alian demandon, kaj tiu listo ankoraŭ montras ŝablonon, kiam nenio estas kreita:

systemctl list-unit-files 'openvpn*'

Legu ambaŭ listojn kune, ĉar ŝablono en la dua kaj instanco en la unua estas malsamaj respondoj. Ŝablono, kiu ekzistas, kaj instanco, kiu ruliĝas, ne estas la sama fakto, kaj nur la dua signifas tunelon. Pakaj aranĝoj ankaŭ varias inter distribuaĵoj kaj OpenVPN-versioj. Pli malnova ŝablono openvpn@, apartigita paro client kaj server, kaj distribua ĉirkaŭaĵo ĉiuj povas esti legitaj en sia propra pakado.

Adaptu al via maŝino, ne al la lernilo, kiun vi trovis. La instanca nomo en la eligo de iu alia povas esti office dum via estas home aŭ work. Transdoniĝas la metodo, ne la signoĉeno.

Sekvu la instancan nomon ĝis la dosiero, kiun ĝi legas

En la upstream-client-ŝablono la labora dosierujo de la unuo estas /etc/openvpn/client kaj ĝia komando prenas %i.conf de tie, do openvpn-client@office legas /etc/openvpn/client/office.conf. Konfirmu tiun mapadon sur la instalita unuo anstataŭ fidi la ekzemplon, ĉar la ŝablono, kiun vi havas, povas esti pli malnova aŭ distribua reverko:

systemctl cat [email protected]

Legu la drop-in dosierojn, kiuj aperas ĉe la fundo de tiu eligo, ĉar dosiero sub .d/ povas ŝanĝi ExecStart, la laboran dosierujon aŭ la konfiguracian vojon. Profilo, kiun vi elŝutis kiel office.ovpn, ne estas la dosiero, kiun la instanco malfermas. Tiu breĉo estas la kutima kialo, ke eraro nomas vojon, kiun vi neniam redaktis.

Relativaj vojoj ene de la profilo estas la sekva kaptilo. Movi la ĉefan dosieron dum la referencoj ca, cert kaj key restas relativaj interŝanĝas mankantan-dosieran eraron kontraŭ alia mankanta-dosiera eraro. La dua montras al dosiero, pri kies ekzisto vi estis certa, kaj tial la profila dosierujo pli gravas ol la dosiernomo.

Lanĉu ĝin, poste legu la ĵurnalon de tiu instanco

Lanĉu la instancon, kiun vi ĵus ekzamenis, ĉar la log de la agregita unuo ne enhavos la erarojn de la tunelo. Poste legu la ĵurnalon por ĉi tiu starto kaj serĉu laŭ tiu ordo konfiguracion eraron, dosieraliron-eraron kaj konektan eraron, ĉar ĉiu malsukcesas en malsama stadio de la starto.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Starti kaj ebligi estas apartaj decidoj: start rulas la uniton nun, enable aranĝas la sekvan starton, kaj enable --now faras ambaŭ en unu paŝo. daemon-reload relegas unitajn difinojn kaj nek restartigas rulantan procezon nek aplikas redaktitan profilon. Post kiam vi ŝanĝis la profilon, restartigu la instancon, ĉar tio relegas la dosieron.

Ne metu duan administrilon sur la saman tunelon

NetworkManager kaj la OpenVPN 3-sesiaj administriloj posedas sian propran konektan staton, kaj systemd-instanco apud unu el ili metas du posedantojn sur la saman tunelon. La simptomo estas tunelo, kiu leviĝas kaj estas anstataŭigita kelkajn sekundojn poste, aŭ tia, kiu rifuzas resti haltigita. Elektu la administrilon, kiun via distribuaĵo dokumentas por la labortablo, kaj uzu systemd konscie sur servilo.

Kontrolu ekzistantan posedanton antaŭ ol lanĉi instancon. Kiam labortabla applet montras la konekton, la instanco, kiun vi lanĉas, konkurigas kun ĝi anstataŭ kompletigi ĝin. Malŝaltu la administrilon, kiun vi ne uzas, anstataŭ ruli ambaŭ kaj esperi, ke la ordo teniĝos. Tiu konflikto ankaŭ klarigas ĵurnalojn, kie tunelo establiĝas kaj poste disfalas pro procezo, kiun vi neniam lanĉis.

Respondu la originan demandon per la instanca nomo, la dosiero, kiun ĝi legis, kaj la ĵurnala linio, kiu malsukcesis. La notoj de OpenVPN pri systemd-integriĝo priskribas la ŝablonan aranĝon kaj la dosieran mapadon, per kiu la instanca nomo solviĝas.