Ĉu OpenVPN lanĉiĝas sen eraro? Rigardu la ĵurnalon

La komando revenas, la servo montriĝas kiel malsukcesa, kaj nenio simila al klarigo atingas la terminalon. Tiu silento estas la simptomo, kiun homoj priskribas kiel «OpenVPN ne lanĉiĝas», kaj ĝi preskaŭ neniam signifas, ke la programo mortis sen diri ion. Ĝi signifas, ke la mesaĝo iris al kanalo, kiun vi ne legis, aŭ ke tio, kion vi lanĉis, ne estis tio, kion vi agordis. Ambaŭ kazoj estas diagnozeblaj en malpli ol minuto, post kiam vi ĉesas konsideri la profilon la suspektato.

Kvar lokoj sorbas la eligon: la ĵurnalo de la unuo, la kromaĵo, kiu posedas la konekton, la alia fino de la tunelo kaj alia duumaĵo ol tiu, kiun vi pensas, ke ĝi ruliĝas. Ĉiu havas sian propran kontrolon.

Silento signifas, ke vi ne observis la ĝustan kanalon

Antaŭplana alvoko printas al via terminalo. Unuo printas al la ĵurnalo, kaj malsukcesa unuo povas eliri antaŭ ol ĝi skribos ion ajn, se la malsukceso estas en kiel ĝi estis lanĉita, ne en tio, kio estis dirita al ĝi. La distingo gravas: neniu ĵurnala ero signifas, ke la procezo neniam vere ruliĝis, dum unu ero sekvata de eliro signifas, ke ĝi ruliĝis kaj rifuzis ion.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Aldonu systemctl show -p Result -p ExecMainStatus openvpn-client@office por apartigi puran eliron de signalo. Statuso 1 kun Result=exit-code estas decido de la programo; Result=signal aŭ tempolimo indikas anstataŭe la medion, kaj neniu kvanto da profilredaktado tion ŝanĝos. Notu ambaŭ valorojn antaŭ ol rekomenci ion ajn, ĉar rekomenco forviŝas la paseman staton, kiu produktis ilin.

La instanca nomo estas parto de la vojo

La pakaĵa ŝablona unuo ne prenas dosiervojon. Ĝi prenas instancan nomon, kaj tiu nomo estas aldonata al dosierujo por trovi la profilon: office solviĝas al /etc/openvpn/client/office.conf en la Debian kaj Ubuntu pakaĵoj. Dosiero nomata office-v2.conf lanĉita kiel @office neniam estas legata, kaj la unuo eliras silente, ĉar laŭ ĝia vidpunkto nenio estis farenda. La serĉa dosierujo diferencas inter klienta kaj servila reĝimo, do la sama eraro montras tute aliloken kiam vi ŝanĝas la ŝablonon.

Tiu nekongruo estas la plej ofta fonto de la silenta malsukceso, kaj ĝi estas nevidebla en la profilo, ĉar la profilo estas en ordo. Listigu, kio efektive ekzistas, kaj komparu la du nomojn signon post signo, inkluzive de ajna finaĵo, kiun la pakaĵo atendas.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Se la unuo estas ebligita sed neniu instanco estas listigita, la ebligo mem povas referenci nomon, kiu poste estis renomita. Reŝalti la ĝustan instancon kutime sufiĉas, kaj la malnova lasita unuodosiero indas esti forigita, por ke ĝi ne konfuzu la sekvan personon. Lasita unuodosiero estas malgranda afero, kiu poste kostas al iu horon.

Kiam la kromaĵo posedas la tunelon, la terminalo vidas nenion

Konekto lanĉita el la labortabla apleto estas posedata de NetworkManager, kaj ĝia OpenVPN-eligo iras al la ĵurnalo de tiu servo anstataŭ al iu ajn ŝelo, kiun vi havas malfermita. Ruli la klienton permane kaj vidi nenion estas atendite en tiu aranĝo, ĉar la permane rulita procezo ne estas tiu, kiu portas la konekton.

Serĉu en la ĵurnalo la servon, kiu posedas ĝin, poste reproduktu la analizon kun detaleco, kiun vi povas legi. La du komandoj sube rigardas malsamajn posedantojn de la sama malsukceso.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

La memstara rulo servas por legi mesaĝojn, ne por anstataŭigi la administritan konekton, kaj la du diferencas poste: DNS-integriĝo, itineroj kaj vivdaŭro apartenas al la kromaĵo. Ripari analizan eraron en la memstara rulo ne aŭtomate riparas la nomrezolucion, kiam la apleto transprenas, do tenu la du observojn aparte.

Du duumaĵoj, unu PATH

Permane instalita versio sub /usr/local venkas ĉe ŝela alvoko, ĉar /usr/local/sbin antaŭas /usr/sbin en la defaŭlta Ubuntu PATH. Unuo ne uzas vian PATH; ĝi rulas la absolutan vojon skribitan en ExecStart. Do la versio, kiu funkcias en via terminalo, kaj la versio, kiu malsukcesas kiel servo, povas esti vere malsamaj programoj.

Komparu la du antaŭ ol rekonstrui ion ajn. La tria komando estas tiu, kiu decidas la argumenton.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Ankoraŭ unu media diferenco kaŝiĝas en la sama loko. Pakaĵa unuo dependas de rulmedia dosierujo sub /run kiun systemd kreas por ĝi; permane skribita anstataŭa unuo, kiu preterlasas tiun agordon, povas malsukcesi antaŭ ol malfermi unu dosieron, kaj la malsukceso aspektas kiel ĝenerala rifuzo sen iu OpenVPN-mesaĝo.

Malsukcesoj, kiujn la kliento ne povas raporti

Iuj rezultoj decidiĝas ĉe la fora fino. Enirejo, kiu respondas per HTTP-statuso kaj fermas la konekton, diris al vi pri sia propra stato, kaj la utila sekva paŝo estas ĝia protokolo aŭ la konto malantaŭ la legitimilo, ne viaj lokaj dosieroj. Nenio loka estas rompita en tiu scenaro, kaj redakti la profilon por kompensi tion malfaciligas la sekvan diagnozon. Legu tiun protokolon antaŭ ol tuŝi la klientan agordon.

Alia silenta kazo estas kliento, kiu funkcias ĝuste. Tunelo en klienta reĝimo neniam aŭskultas pordon, do kontrolo, kiu atendas malfermitan aŭskultanton, raportos nenion kaj aspektos kiel malsukceso. Konfirmu, kiun reĝimon vi lanĉis, antaŭ ol tiri konkludon el malplena pordolisto.

Tradu la tavolojn laŭ ordo: ĉu la unuo ekzistas kaj ĉu la instanca nomo estas ĝusta, ĉu io atingis la ĵurnalon aŭ la dosieron --log, kiuj duumaĵo kaj profilo efektive ruliĝis, kaj ĉu la malsukceso estas loka aŭ fora. Ĉiu respondo forigas tavolon. Komenci de la profilo signifas reverki dosieron, kiu eble neniam estis malfermita.