OpenVPN neieslēdzas bez kļūdas? Apskatiet journal
Klusa iziešana Ubuntu parasti nozīmē, ka ziņojums aizgāja citur vai unit nekad netika palaists. Vispirms pārbaudiet instances nosaukumu, journal un bināro failu.
Komanda atgriežas, pakalpojums tiek parādīts kā neizdevies, un nekas, kas līdzinās skaidrojumam, nenonāk līdz terminālim. Šis klusums ir simptoms, ko cilvēki apraksta kā «OpenVPN neieslēdzas», un tas gandrīz nekad nenozīmē, ka programma nomira, neko nepasakot. Tas nozīmē, ka ziņojums aizgāja uz kanālu, kuru jūs nelasījāt, vai ka tas, ko palaidāt, nebija tas, ko konfigurējāt. Abus gadījumus var diagnosticēt mazāk nekā minūtē, tiklīdz pārstājat uzskatīt profilu par aizdomās turamo.
Izvadi absorbē četras vietas: unit journal, spraudnis, kuram pieder savienojums, otrs tuneļa gals un cita binārā fails nekā tas, kas, jūsuprāt, darbojas. Katram ir sava pārbaude.
Klusums nozīmē, ka jūs vērojāt nevis īsto kanālu
Izsaukums priekšplānā drukā uz jūsu termināli. Unit drukā uz journal, un neizdevies unit var iziet vēl pirms kaut ko ieraksta, ja kļūda ir tajā, kā tas tika palaists, nevis tajā, kas tam tika pateikts. Šī atšķirība ir svarīga: nav ieraksta journal nozīmē, ka process nekad nav īsti darbojies, savukārt viens ieraksts un pēc tam iziešana nozīmē, ka tas darbojās un kaut ko noraidīja.
systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager
Pievienojiet systemctl show -p Result -p ExecMainStatus openvpn-client@office lai atdalītu tīru iziešanu no signāla. Statuss 1 ar Result=exit-code ir programmas lēmums; Result=signal vai taimauts norāda uz vidi, un nekāda profila rediģēšana to nemainīs. Pierakstiet abas vērtības pirms kaut kā restartēšanas, jo restarts izdzēš pārejošo stāvokli, kas tās radīja.
Instances nosaukums ir ceļa daļa
Iepakotais šablona unit nepieņem faila ceļu. Tas pieņem instances nosaukumu, un šis nosaukums tiek pievienots mapī, lai atrastu profilu: office Debian un Ubuntu pakotnēs tiek atrisināts uz /etc/openvpn/client/office.conf. Fails ar nosaukumu office-v2.conf, palaists kā @office nekad netiek lasīts, un unit klusi iziet, jo no tā viedokļa nebija ko darīt. Meklēšanas mape atšķiras klienta un servera režīmā, tāpēc tā pati kļūda, mainot šablonu, norāda pavisam citur.
Šī neatbilstība ir visbiežākais klusās kļūmes avots, un tā profilā nav redzama, jo profils ir kārtībā. Uzskaitiet, kas patiešām pastāv, un salīdziniet abus nosaukumus zīmi pa zīmei, ieskaitot jebkuru paplašinājumu, ko pakotne gaida.
ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all
Ja unit ir iespējots, bet nav uzskaitīta neviena instance, pati iespējošana var norādīt uz nosaukumu, kas vēlāk tika pārdēvēts. Pareizās instances atkārtota iespējošana parasti ir pietiekama, un atlikušo veco unit failu ir vērts dzēst, lai tas nesajauktu nākamo cilvēku. Atstāts unit fails ir sīkums, kas vēlāk kādam izmaksā stundu.
Kad spraudnis pārvalda tuneli, terminālis neko neredz
Savienojumu, kas sākts no darbvirsmas applet, pārvalda NetworkManager, un tā OpenVPN izvade nonāk šī pakalpojuma journal, nevis jūsu atvērtajā shell. Palaist klientu ar roku un neko neredzēt šajā izkārtojumā ir gaidīti, jo ar roku palaistais process nav tas, kas nes savienojumu.
Journal meklējiet pakalpojumu, kuram tas pieder, pēc tam atkārtojiet parsēšanu ar tādu detalitāti, ko varat izlasīt. Divas zemāk esošās komandas skatās uz dažādiem tās pašas kļūmes īpašniekiem.
journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log
Atsevišķā palaišana ir domāta ziņojumu lasīšanai, nevis pārvaldītā savienojuma aizstāšanai, un abi pēc tam atšķiras: DNS integrācija, maršruti un dzīves ilgums pieder spraudnim. Parsēšanas kļūdas labošana atsevišķā palaišanā automātiski nelabo nosaukumu atrisināšanu, kad applet pārņem vadību, tāpēc turiet abus novērojumus atsevišķi.
Divi binārie faili, viens PATH
Ar roku būvēts instalējums zem /usr/local uzvar shell izsaukumā, jo /usr/local/sbin nāk pirms /usr/sbin Ubuntu noklusējuma PATH. Unit neizmanto jūsu PATH; tas izpilda absolūto ceļu, kas ierakstīts ExecStart. Tāpēc versija, kas darbojas jūsu terminālī, un versija, kas neizdodas kā pakalpojums, var būt patiešām dažādas programmas.
Salīdziniet abas pirms kaut kā pārbūvēšanas. Trešā komanda ir tā, kas izšķir strīdu.
command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart
Vēl viena vides atšķirība slēpjas tajā pašā vietā. Iepakotais unit paļaujas uz izpildes mapi zem /run , ko systemd tam izveido; ar roku rakstīts aizvietotājunit, kas izlaiž šo iestatījumu, var neizdoties vēl pirms vienas faila atvēršanas, un kļūme izskatās kā vispārējs atteikums bez jebkāda OpenVPN ziņojuma.
Kļūmes, par kurām klients nevar ziņot
Daži iznākumi tiek izlemti tālajā galā. Vārteja, kas atbild ar HTTP statusu un aizver savienojumu, jums pastāstīja par savu stāvokli, un nākamais lietderīgais solis ir tās žurnāls vai konts aiz akreditācijas datiem, nevis jūsu vietējie faili. Šajā scenārijā nekas vietējais nav salauzts, un profila rediģēšana kompensācijai padara nākamo diagnostiku grūtāku. Izlasiet šo žurnālu pirms klienta konfigurācijas aizskaršanas.
Vēl viens kluss gadījums ir pareizi darbojošs klients. Klienta režīma tunelis nekad neklausās portā, tāpēc pārbaude, kas gaida atvērtu klausītāju, neko neziņos un izskatīsies kā kļūme. Apstipriniet, kuru režīmu palaidāt, pirms izdarāt secinājumu no tukša portu saraksta.
Apstrādājiet slāņus pēc kārtas: vai unit pastāv un vai instances nosaukums ir pareizs, vai kaut kas nonāca journal vai failā --log , kurš binārais fails un profils patiešām darbojās, un vai kļūme ir vietēja vai attāla. Katra atbilde noņem vienu slāni. Sākt ar profilu nozīmē pārrakstīt failu, kas, iespējams, nekad nav ticis atvērts.