OpenVPN rāda active (exited)? Atrodiet instanci, kuru palaidāt
active (exited) nav tunelis, bet vienreizējs /bin/true uzdevums, ko uztur RemainAfterExit. Atrodiet instanci, izlasiet failu, uz kuru tā norāda, un pēc tam izlasiet tās žurnālu.
Jūs pārbaudāt tuneli, palaižat systemctl status openvpn un iegūstat active (exited) bez Main PID un ar tukšu procesu sarakstu. Dabiskā lasīšana ir tāda, ka pakalpojums startējis un nomiris, tāpēc jūs atverat unit, atrodat /bin/true un secināt, ka pakotne ir salauzta. Debian pakotnē šis stāvoklis ir wrapper, kas strādā kā paredzēts, un tunelis dzīvo vienā no instance unit, ko tas palaiž. Kopējais unit nekad nepateiks, kura instance to uzbūvēja.
Ko active (exited) šajā unit patiešām nozīmē
Iepakotais unit ir vienreizējs uzdevums: tā ExecStart ir /bin/true, un RemainAfterExit=yes ir tas, kas pabeigtu unit tur paziņotu kā active (exited). Noņemiet šo direktīvu, un tas pats veiksmīgais /bin/true uzdevums beidzas inactive (dead), kas ir tieši tas stāvoklis, ko cilvēki gaida un nepareizi nolasa pretējā virzienā. Komanda ir tikai aizstājējs, un unit ziņo par darbu, ko veic citi unit. Šajā izkārtojumā nekas nav salauzts, un /bin/true aizstāšana maina pakotnes līgumu, nevis tuneli.
Wrapper deleģē. Tas palaiž instance unit, ko nodrošina pakotnes konfigurācija vai tās systemd ģenerators, tāpēc tukšs procesu saraksts neko nepierāda par tuneli. Kad nav izvēlēta neviena instance, wrapper joprojām gūst panākumus un joprojām neko nepalaida. Stāvoklis atbild, vai wrapper darbojās, nevis vai pastāv tunelis.
Lasiet trīs status izvades rindas, nevis vārdu iekavās. Loaded nosauc unit failu, ko systemd izlasīja, Active nes pēdējās veiksmīgās palaišanas laika zīmi, un trūkstošais Main PID atbilst pabeigtam vienreizējam uzdevumam. Šīs trīs rindas ir arī veids, kā atšķirt šo wrapper no pakalpojuma, kas sabruka sekundi pēc starta.
Uzskaitiet unit, pirms vēlreiz lasāt status
Pajautājiet systemd, kas pastāv, pirms jautājat, kas darbojas. Šablons var būt instalēts, kamēr nav izveidota neviena instance, un tikai izveidots unit nes tuneli. Sāciet ar ielādēto kopu:
systemctl list-units 'openvpn*'
Šis saraksts ir tas, ko systemd šobrīd ielādēja, un tas ir vistuvākais tuneļu uzskaitei. Instalētie unit faili atbild uz citu jautājumu, un šis saraksts joprojām rāda šablonu, kad nekas nav izveidots:
systemctl list-unit-files 'openvpn*'
Lasiet abus sarakstus kopā, jo šablons otrajā un instance pirmajā ir divas dažādas atbildes. Esošs šablons un darbojošās instance nav viens un tas pats fakts, un tikai otrais nozīmē tuneli. Pakotņu izkārtojumi atšķiras arī starp distribūcijām un OpenVPN versijām. Vecāks openvpn@ šablons, atsevišķs client un server pāris un distribūcijas wrapper var būt likumīgi savā pakotnē.
Pielāgojiet savai mašīnai, nevis atrastajai apmācībai. Instances nosaukums cita izvadē var būt office, kamēr jūsējais ir home vai work. Tiek nodota metode, nevis virkne.
Sekojiet instances nosaukumam līdz failam, ko tā lasa
Upstream client šablonā unit darba direktorija ir /etc/openvpn/client un tā komanda no turienes ņem %i.conf, tāpēc openvpn-client@office lasa /etc/openvpn/client/office.conf. Apstipriniet šo atbilstību instalētajā unit, nevis uzticieties piemēram, jo jūsu šablons var būt vecāks vai distribūcijas pārrakstīts:
systemctl cat [email protected]
Lasiet drop-in, kas parādās šīs izvades apakšā, jo fails zem .d/ var mainīt ExecStart, darba direktoriju vai konfigurācijas ceļu. Profils, ko lejupielādējāt kā office.ovpn, nav fails, ko instance atver. Šī plaisa ir parastais iemesls, kāpēc kļūda nosauc ceļu, ko nekad neesat rediģējis.
Relatīvie ceļi profila iekšienē ir nākamās lamatas. Pārvietojot galveno failu, kamēr ca, cert un key atsauces paliek relatīvas, jūs nomaināt pazuduša faila kļūdu pret citu pazuduša faila kļūdu. Otrā norāda uz failu, par kura esamību bijāt pārliecināts, tāpēc profila direktorija ir svarīgāka par faila nosaukumu.
Palaidiet to un pēc tam lasiet tās instances žurnālu
Palaidiet instanci, kuru tikko pārbaudījāt, jo kopējā unit žurnālā nebūs tuneļa kļūdu. Pēc tam lasiet šīs palaišanas žurnālu un šajā secībā meklējiet konfigurācijas kļūdu, faila piekļuves kļūdu un savienojuma kļūdu, jo katra no tām neizdodas citā starta posmā.
sudo systemctl start [email protected]
journalctl -u [email protected] -b
Palaišana un iespējošana ir atsevišķi lēmumi: start izpilda unit tagad, enable sakārto nākamo palaišanu, un enable --now dara abus vienā solī. daemon-reload nolasa unit definīcijas no jauna un nepārstartē darbojošos procesu un nepiemēro rediģētu profilu. Pēc profila maiņas pārstartējiet instanci, jo tas ir tas, kas nolasa failu no jauna.
Nelieciet otru pārvaldnieku uz tā paša tuneļa
NetworkManager un OpenVPN 3 sesiju pārvaldniekiem ir savs savienojuma stāvoklis, un systemd instance blakus vienam no tiem liek divus īpašniekus uz tā paša tuneļa. Simptoms ir tunelis, kas paceļas un pēc dažām sekundēm tiek aizstāts, vai tāds, kas atsakās palikt apturēts. Izvēlieties pārvaldnieku, ko jūsu distribūcija dokumentē darbvirsmai, un serverī apzināti izmantojiet systemd.
Pirms instances palaišanas pārbaudiet, vai jau ir īpašnieks. Kad darbvirsmas applet rāda savienojumu, palaistā instance ar to konkurē, nevis to papildina. Atspējojiet neizmantoto pārvaldnieku, nevis palaidiet abus un ceriet, ka kārtība saglabāsies. Šis konflikts izskaidro arī žurnālus, kuros tunelis tiek izveidots un pēc tam sagrauts ar procesu, ko nekad neesat palaidis.
Atbildiet uz sākotnējo jautājumu ar instances nosaukumu, tās izlasīto failu un neveiksmīgo žurnāla rindu. OpenVPN piezīmes par systemd integrāciju apraksta šablona izkārtojumu un faila atbilstību, caur kuru tiek atrisināts instances nosaukums.