Konekto de OpenVPN malsukcesas, iu trovas unulinian riparon, kiu aldonas SECLEVEL=0, kaj la tunelo ekfunkcias. Tio, kio ŝanĝiĝis, estis nek la atestilo nek la ĉifra aro; moviĝis akcepta sojlo de la tuta biblioteko, kaj ĉio, kion la procezo faras poste, heredas la novan limon. Indas kompreni tion antaŭ ol la sama linio estos kopiita en ĉiun profilon de la medio.

Determini, kiu biblioteko kaj kiu politiko validas

SECLEVEL estas koncepto de OpenSSL, do la unua demando estas, ĉu via konstruaĵo entute uzas OpenSSL. OpenVPN povas esti ligita al pli ol unu kriptografia biblioteko, kaj agordo, kiu validas por unu el ili, estas sensenca por la aliaj. Demandu la binaran dosieron, per kio ĝi estis konstruita, poste demandu la bibliotekon, kiun version kaj agordon ĝi ŝargis:

openvpn --version | head -3
openssl version -a

Legi la eligon de la versio atente, ĉar distribuaĵoj flikas defaŭltojn. Iuj liveras sisteman agordon, kiu altigas la minimuman nivelon super la defaŭlto de upstream, kaj tial la sama profilo kondutas alie sur du maŝinoj kun identaj OpenVPN-paketoj. La efektiva politiko estas tiu, kiun ŝargis la kuranta procezo, ne tiu en la manlibro de upstream.

Poste apartigu la du tavolojn, kiujn homoj konfuzas. OpenVPN havas proprajn TLS-kontrolojn, inkluzive de agordo de atestila profilo kaj eksplicitaj ĉifraj listoj, kaj tiuj staras super ĉio, kion la biblioteko devigas. Malaltigi la bibliotekan nivelon ne ŝanĝas, kiujn ĉifrojn via OpenVPN-agordo listigas, kaj mallarĝigi la OpenVPN-liston ne altigas la sojlon de la biblioteko. Scii, kiu tavolo malakceptis vin, estas tio, kio malhelpas, ke la riparo restu konjekto.

Apartigu la tri aferojn, kiuj povas esti malakceptitaj

La unua kandidato estas identeca materialo: atestilo, kies ŝlosilo estas tro malgranda aŭ kies subskriba algoritmo ne plu estas akceptata de la politiko. La dua estas ŝlosilinterŝanĝa parametro, kiel grupo, kiun la politiko konsideras tro malforta. La tria estas ĉifra aro, kiun la politiko ekskludas. Ĉiuj tri povas kaŭzi malsukceson de manpremo, kaj nur la erarteksto kaj la intertrakta fazo distingas ilin.

Neniu el tiuj tri estas la ĉifro de la datena kanalo. OpenVPN intertraktas sian tunelan ĉifradon aparte de la TLS-manpremo, do konekto, kiu sukcesas post ŝanĝo de sekureca nivelo, diras nenion pri tio, kiu ĉifro protektas viajn datumojn. Se la demando, kiun vi efektive starigas, koncernas la konfidecon de la datumoj, vi rigardas tute malĝustan butonon.

Malaltigi la nivelon plilarĝigas la akcepton por ĉiuj tri enigoj samtempe. Tio estas la parto, kiun homoj maltrafas: la riparo, kiu enlasas malnovan atestilon, enlasas ankaŭ malfortan grupon kaj aron, kiun vi eble ne intencis permesi. Unu eraro kaŭzis la ŝanĝon, kaj la ŝanĝo estas pli larĝa ol la eraro. Tiu asimetrio estas la kialo, kial limigita escepto superas defaŭlton por la tuta medio.

Ŝanĝu la enigon, ne la sojlon

Konservu la precizan eraron antaŭ ol tuŝi la agordon, inkluzive de la fazo, kiu raportis ĝin, kaj la objekto, kiun ĝi nomis. Atestila problemo solviĝas anstataŭigante la atestilon per io, kion la nuna politiko akceptas, kio kutime signifas reeldonon ĉe la aŭtoritato anstataŭ reinstali la saman dosieron.

Se la malakceptita enigo apartenas al samtavolano, kiun vi ne kontrolas, la interparolo estas kun ties posedanto pri subtenata anstataŭa materialo. Malaltigi vian propran sojlon por gastigi sistemon, kiun neniu prizorgas, translokas la koston de ili al ĉiuj, kiuj konektiĝas post ili.

Kie la servilo devigas la politikon, kontrolu, ĉu OpenVPN-nivela agordo estas la reala kaŭzo, antaŭ ol kulpigi la bibliotekon. Atestila profilo, kiu postulas pli severan klason ol tiu, kiun la deplojita atestilo povas plenumi, malsukcesos sendepende de la sekureca nivelo, kaj forigi tiun profilon estas pli mallarĝa ŝanĝo ol malŝalti la kontrolojn de la biblioteko.

Se vi devas malaltigi ĝin, limigu ĝin kaj registru ĝin

Foje aprobita kongrueca escepto estas la ĝusta respondo, aparte por malnova samtavolano kun datita foriga plano. Limigu ĝin al la servo, kiu bezonas ĝin, anstataŭ al la tuta gastiganto: agorda dosiero por unu servo aŭ dediĉita OpenSSL-agordo havas pli malgrandan efikradiuson ol eksporto en la tuta profilo.

Skribu kvar aferojn kun la escepto: la precizan agordon, la posedanton, kiu aprobis ĝin, la klientojn, kiujn ĝi tuŝas, kaj la kondiĉon, sub kiu ĝi estos forigita. Escepto sen foriga kondiĉo estas permanenta malfortigo kun aldona provizora pravigo.

Reveno devus esti unu paŝo, kiun vi jam testis. Konservu la antaŭan agordon, apliku la ŝanĝon, konfirmu, ke la servo ekfunkcias, kaj sciu precize, kiun dosieron restarigi, se la sekva konekto kondutos alie ol atendite.

Poste kontrolu identecon kaj protekton

Sukcesa konekto pruvas nur, ke la reviziitaj kondiĉoj akceptis ĝin. Konfirmu, ke kontrolado de gastigantnomo kaj samtavolano ankoraŭ faras sian laboron, ke la uzata atestilo estas tiu, kiun vi intencis deploji, kaj ke la intertraktita datena kanalo kongruas kun la politiko, kiun vi pensas havi.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

La OpenSSL-referenco pri sekurecaj niveloj klare diras, ke la kadro aplikas limojn al ŝlosiloj, subskriboj, grupoj kaj aroj kune, kaj ke nivelo nulo permesas ĉion, kion la retrovoko kontrolas. Tio estas la amplekso de tio, kion vi ŝanĝis, kaj tio estas la frazo, kiun citi, kiam iu demandas, ĉu la riparo estis mallarĝa.

La transdono, kiu postvivas revizion, diras, kiu politiko malakceptis kiun enigon, kio estis ŝanĝita kaj kio restas akceptata rezulte. „Ĝi funkcias kun SECLEVEL=0“ estas observo pri unu konekto, ne sekureca takso de la deplojo.

Rilataj artikoloj