OpenVPN 3 Linux: legu D-Bus-eraron antaŭ ol retroiri

Malsukcesoj de OpenVPN 3 Linux alvenas kiel D-Bus-metoda eraro kun nekonata nomo alkroĉita, kaj la tento estas malaltigi pakaĵon kaj esperi. La kliento ne estas unu programo: komandlinia fasado parolas tra la buso kun servoj, kiuj posedas profilon, sesiojn, la VPN-motoron kaj la privilegiajn retajn ŝanĝojn. Decidi, kiu el tiuj kvin posedas la malsukcesan vokon, estas la plej granda parto de la diagnozo, kaj ĝi kostas unu komandon anstataŭ retroiron. Tio, kio sekvas, estas tiu decido, en la ordo en kiu la malsukcesoj kutime aperas.

Kvin posedantoj malantaŭ unu komando

Kvin procezoj gravas, kaj ĉiu havas propran busan nomon: la fasado, kiu akceptas vian komandon, la administranto de agordoj, kiu konservas profilojn kaj ilian alirpolitikon, la administranto de sesioj, kiu posedas la vivdaŭron de sesio, la malantaŭaĵo, kiu funkciigas la konekton per OpenVPN 3 Core Engine, kaj la reta agorda servo, kiu instalas la interfacon, la itinerojn kaj la DNS-agordojn. Eraro, kiu nomas agordan objekton, do ne estas malantaŭaĵa eraro, kaj malantaŭaĵo, kiu ne ekfunkcias, ne estas aŭtentiga malsukceso. Enordigi la mesaĝon en unu el tiuj linioj devas okazi antaŭ ol io ajn ŝanĝiĝu, ĉar ĉiu posta paŝo dependas de tio, kiu linio estas vera. Diveni la linion estas la maniero, kiel mallonga riparo fariĝas posttagmezo da paka laboro.

Demandu la sisteman buson, kiuj servoj ĉeestas, antaŭ ol demandi ion ajn alian, poste konfirmu, ke la instalitaj pecoj konsentas pri versio. OpenVPN 3 Linux registras tiujn servojn kiel sistemunuojn, do la buso demandenda estas la sistema buso, la versia demando bezonas administran aŭtoritaton, kaj listo farita per --user legas vian ensalutan sesion, kie la unuoj neniam aperas. Servoj aktivigas laŭ peto kaj kelkaj eliras kiam ili estas senokupaj, do servo mankanta antaŭ via unua peto simple ankoraŭ ne estis demandita pri io. La tri komandoj sube respondas pri ĉeesto, versio kaj unuostato sen malfermi VPN-sesion.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Kion ĉiu listo vere pruvas

La propraj vidpunktoj de la kliento estas la plej malmultekosta havebla pruvo, kaj ĉiu el ili pruvas malpli ol ĝi ŝajnas. Profilo en la agorda listo montras, ke profilo estas importita, kaj nenion pri tio, ĉu iu rajtas konektiĝi per ĝi. Sesio en la sesia listo montras, ke sesia objekto ekzistas, kaj nenion pri tio, ĉu la fora aŭtentigo finiĝis.

openvpn3 configs-list
openvpn3 sessions-list

Objektaj vojoj en tiuj eligoj nomas administratajn objektojn sur la buso kaj ne dosierojn, do ili ne povas esti redaktitaj, kaj vojo antaŭe notita malaktualiĝas en la momento, kiam tiu sesio malkonektiĝas. Reuzi unu el viaj notoj produktas "no such object"-erarojn, kiuj havas nenion komunan kun la VPN. La etapa tabelo sube apartigas tion, kion ĉiu paŝo de konekto starigas, de tio, kion ĝi lasas malfermita, kaj ĝuste tiu distingo estas la bazo de retroira decido. Legu la linion, kiu kongruas kun via pruvo, poste relegu la eraran tekston.

La konekta voko revenas antaŭ ol la tunelo ekzistas

La konekta voko donas al vi sesion por observi kaj revenas, tial ŝajne sukcesa voko sekvita de silento estas normala meza stato kaj ne kontraŭdiro. La fasado ankoraŭ devas sekvi statŝanĝojn kaj respondi al ĉiu peto pri interagado. Profilo, kiu bezonas akreditilon kaj ricevas neniun respondon, atendas en stato, kiu aspektas ĝuste kiel blokita malantaŭaĵo. Tiu atendostato meritas rekonon, ĉar ĝi sendas homojn al la malĝusta komponento.

Dum provo funkcias, observu la sesian liston kaj la propran protokolon de la fasado por tiu profilo. Sesio, kiu neniam forlasas sian komencan staton, nomas la komponenton, kiu haltis, kaj la protokolo kutime nomas ĝin jam en la unuaj linioj. Tenu la profilan nomon proksime, ĉar la protokola komando prenas profilon kaj ne sesian vojon, kio estas plia kialo relegi la liston anstataŭ reuzi vojon.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Legi la protokolon de unu komponento sen malfermi sesion

Kiam la fasado raportas nenion utilan, iru al la komponento, kiu protokolis la malsukceson, anstataŭ komenci alian konekton. Kun agordita systemd-journald protokolilo, la limigita protokola vido de la administranto legas la eventojn de unu komponento sen tuŝi la busan politikon aŭ malfermi sesion, kio gravas ĉar diagnozo, kiu ŝanĝas la sistemon, kiun ĝi mezuras, pruvas tre malmulte. Filtru laŭ unuo kaj ne laŭ syslog-etikedo: la unuopaj servunuoj ne garantias komunan identigilon, do etikeda demando povas redoni malplenan paĝon dum la unuo mem registris la malsukceson.

Notu kvar kampojn antaŭ ol peti helpon de iu: la plenan eraran nomon, la koncernan servon kaj objekton, la tempomarkon kaj la versiojn de la instalitaj pakaĵoj. Tiuj estas tio, kion bezonas prizorganto, kaj neniu el ili postulas alglui profilon aŭ akreditilon en bileton. Larĝigi la busan alirpolitikon por silentigi la eraron ne estas diagnozo, ĝi forigas la limon, kiu nomis la komponenton por vi. Privata profila enhavo restas ekster komunaĵoj raportoj pro la sama kialo kiel akreditiloj.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Korekti la limon, kiu rifuzis

Ĉiu linio de la mapo havas sian propran korekton, kaj la linioj ne anstataŭas unu la alian. Rifuzita operacio sur profilo estas demando pri politiko kaj proprieto, dum malantaŭaĵo, kiu ne aktivigas, estas demando pri servoj kaj pakumado. Servilo rifuzanta aŭtentigon estas nek unu nek la alia, do ripetitaj pasvortaj ŝanĝoj ne povas ripari lokan aktivigan problemon. Elekti la malĝustan korekton estas la maniero, kiel politika problemo fariĝas reinstalo.

Post paka ŝanĝo, kontrolu koheran kaj subtenatan instalon anstataŭ kopii malnovan binaran dosieron en ĝian lokon. Kontrolita retroiro estas legitima respondo al konfirmita regreso, kondiĉe ke la pakaĵoj restas kongruaj kaj ekzistas vojo reen al subtenata prizorgado. Starigu tiun vojon antaŭ ol la servo ĉesos ekfunkcii, ne poste.

Alia platformo povas dividi la saman kernan VPN-bibliotekon sen dividi la busajn servojn de Linukso, do simile aspektanta malsukceso en Windows diras nenion pri ĉi tio. La superrigardo de D-Bus dokumentas la objektajn vojojn elmetitajn por agordoj kaj sesioj, kaj tio estas la parto de la arkitekturo, sur kiu baziĝas ĉi tiu diagnozo. Legu ĝin unufoje, kaj la sekva eraro alvenos kun komponento jam alkroĉita al ĝi.