Kiun openvpn-dosieron oni efektive rulas? Kontrolu la lanĉan vojon

Malnova provizora solvo movis la efektivigeblon de OpenVPN aliloke kaj lasis ŝelan ĉirkaŭaĵon ĉe la origina vojo. Monatojn poste venas ĝisdatigo, kaj malfari la solvon fariĝas divenludo pri tio, kiu dosiero vere estas la kliento. La komanda nomo, la en la servo agordita efektivigeblo kaj la propra dosierlisto de la pako povas ĉiuj montri al malsamaj objektoj, kaj ripari unu el ili sen la aliaj produktas gastiganton, kiu aspektas riparita kaj kondutas pli malbone.

Komencu per la vojo, kiun la servo lanĉas

Terminalo kaj systemd-unuo ne solvas efektivigeblojn same. La ŝelo serĉas en PATH; la unuo nomas vojon, kaj drop-in-ĉirkaŭigoj povas anstataŭigi ĝin sen tuŝi la dosieron, kiun vi legas. Tiu diferenco klarigas la plejparton de la konfuzo en ĉi tiu tasko. Ĝi ankaŭ decidas, kiun dosieron via riparo devas celi.

Demandu la unuon, kion ĝi efektivigas, inkluzive la drop-in-ojn, kiuj modifas ĝin, kaj legu la rezultan ExecStart-linion anstataŭ la fragmenton, kiun vi supozas aŭtoritata. Poste sekvu tiun vojon tra ajna simbola ligilo al la fina dosiero. Ĉirkaŭaĵo, kiu finiĝas per exec en kaŝitan dosierujon, estas kutima aranĝo el tiuj malnovaj riparoj.

Skribu la solvitan vojon antaŭ ol vi ŝanĝos ion ajn.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Komparu la komandan nomon kun la serva vojo

La du respondoj ofte diferencas, kaj tiu diferenco ne aŭtomate estas difekto. NetworkManager-kromaĵo povas lanĉi sian propran vojon, kaj ujo povas munti ankoraŭ alian.

Grave estas scii, kiu posedanto lanĉas la procezon, kiu servas trafikon. Se la unuo rulas /usr/local/sbin/openvpn-wrapper dum via ŝelo solvas /usr/sbin/openvpn, ripari la duan dosieron ŝanĝas nenion pri la servo.

Demandu, kiu pako posedas ĉiun kandidaton, poste decidu, ĉu la dosiero estas pako-administrata aŭ loke metita. Dosiero sen posedanta pako estas dosiero, kiun iu metis tien intence, kaj ĝi meritas nomon, posedanton kaj kialon antaŭ ol esti forigita. La mala eraro ankaŭ oftas: anstataŭigi pakan dosieron per malnova konservita efektivigeblo ĉar forumafŝo uzis la saman dosierujon.

Lasu la pakan datumbazon paroli pri pakaj dosieroj

Kiam la programaro venis el Debian-pako, la paka datumbazo povas diri al vi, ĉu ĝiaj dosieroj ankoraŭ kongruas kun tio, kio estis instalita. Tio estas mallarĝa integreca demando, ne sekureca verdikto, kaj la diferenco gravas kiam vi decidas, kion ripari. Miskongruo signifas, ke la dosiero ŝanĝiĝis post la instalado, kio povus esti via malnova solvo aŭ laŭleĝa loka redakto. La eligo ne decidas kiun, do legu ĝin kiel indikon, ne kiel konkludon.

Rulu la kontrolon kaj legu la eligon anstataŭ trakti malplenan rezulton kiel pruvon pri io ajn.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

La gvidlibro de dpkg dokumentas, ke la kontrolo komparas instalitajn dosierojn kun loke registritaj metadatenoj, uzante konservitajn kontrolsumojn kie ili ekzistas. Ĝi rimarkas ŝanĝitan pakan dosieron, kaj ĝi ne povas diri al vi, ĉu alia efektivigeblo estas lanĉata anstataŭe.

Registru la staton antaŭ ol ripari

Kolektu la solvitan lanĉan vojon, la pakan rilaton de la dosiero, la lokon de la ĉirkaŭaĵo kaj la ŝanĝregistron, kiu enkondukis ĝin. Kopiu la ĉirkaŭaĵon al protektita loko se ĝi enhavas integran laboron, kiu bezonos poste.

Ne algluu la enhavon de la ĉirkaŭaĵo en subtenan fadenon antaŭ ol legi ĝin, ĉar tiuj skriptoj foje portas akreditaĵojn aŭ detalojn pri la enirejo.

Registru, kiujn profilojn la servo uzas kaj kiu estas konektita dum vi laboras, ĉar restartigo de la tunelo povas interrompi la sesion, per kiu vi administras la gastiganton.

Kontrolu la lanĉon, poste forigu la ĉirkaŭaĵon

Post la riparo, startigu la servon kaj konfirmu, ke la procezo rulas la vojon, kiun vi intencis. Versia demando farita permane pruvas, ke la dosiero funkcias; ĝi ne pruvas, ke la unuo uzas ĝin.

Poste rekonektu klienton kaj kontrolu, ĉu la profilo ankoraŭ aŭtentikigas, ĉar anstataŭigo de efektivigeblo, kiu ignoras la originajn opciojn, malsukcesos tiel, ke ĝi aspektas kiel atestila problemo.

Forigu la delokigitan ĉirkaŭaĵon per la sama ŝanĝregistro, kiu enkondukis ĝin. La finita riparo diras, kiu efektivigeblo rulas, kial, kaj kiu dosiero estis forigita; restarigi dosiernomon kaj esperi ne estas la sama afero.