Kiu OpenVPN-instancaĵo fakte uzas vian PiVPN-profilon?

PiVPN skribas servilan agordon kaj klientan profilon, poste finiĝas; ĝi neniam fariĝas la procezo, kiu portas vian trafikon. Do malsukcesa manpremo, kliento alvokanta malĝustan finpunkton, aŭ servo, kiu post restarto revenas malĝuste, ne klarigeblas per la menuoj de la instalilo. Tiuj simptomoj apartenas al tiu OpenVPN-demono, kiu nun funkcias, al la agordo, kiun tiu demono fakte ŝarĝis, kaj al la protokolo, al kiu ĝi estis direktita. Kvar nurlegaj komandoj kutime solvas tion, kaj neniu el ili ŝanĝas viajn atestilojn aŭ ŝlosilojn.

La helpilo kaj la demono estas malsamaj objektoj

La konfuzo estas facile klarigebla: unu dosierujo enhavas la dosieron, kiun la helpilo generis, la dosieron, kiun la demono legas, kaj foje malnovan kopion de ambaŭ. Helpilo estas provizadskripto. Ĝi instalas pakaĵojn, skribas unuodosierojn kaj printas klientan profilon, kaj tiam ĝia laboro finiĝas. Kio restas, estas enskribo en la servoadministrilo kaj komandlinio.

Sur systemd-gastiganto komencu per la aktiva unuo anstataŭ per la dosieruja listo. La nomo dependas de la pakaĵado: Debian kaj Raspberry Pi OS bildoj kutime montras ŝablonan instancon kiel openvpn-server@server, dum pli malnovaj instalaĵoj uzas openvpn@server. Demandu la administrilon, kiu funkcias, anstataŭ diveni el dosiernomo.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Legu ExecStart= en tiu eligo. Ĝi nomas la plenumeblon kaj la opciojn, kiujn la administrilo fakte lanĉas, inkluzive de iu ajn --config vojo; agorda dosiero apude, al kiu neniu komando referencas, ne estas parto de la kuranta tunelo.

Spuru la agordan ĉenon, kiun la demono solvis

OpenVPN ne skanas dosierujon por agordoj. Ĝi legas la dosieron pasigitan per --config, sekvas ĉiujn config direktivojn ene de ĝi, kaj poste aplikas la komandliniajn opciojn. La manlibro 2.6 priskribas tiun ordon, kaj tio gravas, kiam du dosieroj malkonsentas pri la pordo, la aparato aŭ la ĉifro.

Unue eligu la efektivan alvokon, poste rigardu la direktivojn, kiuj difinas identecon kaj atingeblon. Ambaŭ komandoj estas nurlegaj kaj sekuraj sur viva servilo, kvankam la dua printas vojojn, kiujn vi eble ne volas en publika bileto.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Dosiero .ovpn en hejma dosierujo estas klienta artefakto. La servila demono neniam legas ĝin, do redakti tiun dosieron por ripari servilflankan manpreman fiaskon atingas nenion.

Inkluzivoj estas la alia kaptilo. Linio config enkondukas duan dosieron, kies opcioj estas prilaborataj en tiu punkto, do posta unuvalora direktivo povas anstataŭigi tion, kion la ĉefa dosiero ŝajne diras. Se la videbla dosiero aspektas ĝuste kaj la demono ankoraŭ kondutas alie, legu la inkluzivitan dosieron antaŭ ol ŝanĝi ion.

Parigu la protokolon kun la procezo, ne kun la eraro, kiun vi memoras

Du protokolceloj oftas, kaj nur unu el ili estas la ĵurnalo. Kun log-append agordita, la demono skribas al tiu dosiero kaj la ĵurnalo tenas malmulte krom startlinioj. Sen ĝi, journalctl estas la eventofonto.

journalctl -u openvpn-server@server -n 80 --no-pager

Rilatigu unu konekprovo kun unu tempofenestro. Notu la finpunkton de la kliento, poste legu servilajn eventojn el la samaj sekundoj. TLS-manpremo, kiu neniam atingas la atestilan interŝanĝon, indikas atingeblon aŭ protokolan malkongruon, dum malakcepto de aŭtentikigo venas post kiam la tunelaj parametroj jam interkonsentiĝis.

Malnova protokola enskribo pruvas nenion pri profilo, kiun vi elŝutis antaŭ kvin minutoj. Regeneru la klientan dosieron, konektu unufoje, kaj legu nur la liniojn, kiuj aperis dum tiu provo.

Notu la unuan konkretan fiaskon, ne la lastan ĝeneralan. Bind-eraro, nerespondita ekstera interŝanĝo, atestila malakcepto kaj konta malakcepto ĉiu sendas vin al malsama tavolo, kaj tempolimo ĉe la fino ofte kaŝas la utilan eventon supre.

Rekonstrui la tunelon ne estas diagnoza paŝo

La tenta fuŝsolvo estas starigi duan, pli simplan tunelon: statika ŝlosilo, neniuj atestiloj, neniuj pliaj aŭtentikigoj. Ĝi ofte konektos, kaj ĝi pruvas nur, ke du gastigantoj povas pasigi UDP aŭ TCP inter si. Ĝi diras nenion pri tio, kial la atestila disfaldiĝo malsukcesas, kaj ĝi silente anstataŭigas la sekurec modelon, kiun vi devis konservi.

La samo validas por malŝalti tls-auth aŭ tls-crypt, malstreĉi verify-x509-name, aŭ forlasi duan faktoron por akiri verdan staton. Tunelo, kiu konektas ĉar oni forigis la kontrolon, estas malsama sistemo, ne riparita.

Faru unu limigitan ŝanĝon en la tavolo, kiun la protokolo nomis, restartigu la saman unuon kaj ripetu la ununuran konekprovo. Tio tenas la komparon honesta kaj lasas ŝanĝon, kiun vi povas malfari.

Kion transdoni al la sekva persono

Skribu kvar faktojn, dum vi ankoraŭ havas ilin: la OpenVPN-version el openvpn --version, la unuon, kiu estas aktiva, la agordan ĉenon kun ĝiaj inkluzivoj, kaj la protokolan fenestron kovrantan unu provon. Tiuj kvar transformas nebulan plendon en reprodukteblan kazon.

Kaŝu sentemajn datumojn antaŭ ol kunhavigi. Privataj ŝlosiloj, auth-user-pass kaj aliaj dosieroj, statika ŝlosilmaterialo kaj plenaj klientaj pakaĵoj ne apartenas al bileto; opcinomoj kaj la formo de la ĉeno kutime sufiĉas por dua paro da okuloj.

Se la ĉeno estas sendifekta kaj la protokolo ankoraŭ montras al la reto, la sekva paŝo estas la vojo inter kliento kaj servilo anstataŭ plia instalado. Tio estas la sola parto de la historio, kiun la helpilo neniam posedis.