Rifuzita konekto ne estas atestila problemo: VPN-gvidilo

La kliento diras, ke la konekto rifuziĝis tuj post kiam vi regeneris la CRL, do la CRL ŝajnas kulpa. Ĝi ne estas. Rifuzo estas respondo de la transporta tavolo, kaj atestila validigo okazas pli poste, ene de la tunela manpremo. La tempigo estas kunteksto, ne pruvo.

Du kontroloj apartigas la kazojn en malpli ol minuto, kaj nek unu el ili tuŝas fido-agordojn.

Legu la eraron en la tavolo, kiu produktis ĝin

ECONNREFUSED de connect signifas, ke la transporta provo estis rifuzita: io respondis per reset, aŭ la stako raportis neatingeblan pordon. Atestila problemo ne povas produkti tiun eraron, ĉar la TLS-manpremo neniam komenciĝas sen transporta konekto. Se vi vidas rifuzon, la kliento neniam atingis sufiĉe por prezenti atestilon. Tiu sola fakto ekskludas revokon kiel kaŭzon.

Ankaŭ la malo validas. Revokita atestilo produktas plenumitan TCP-konekton kaj fiaskintan manpremon, registritan en la servilo kiel validiga eraro.

TCP-rifuzo: neniu aŭskultas

Por TCP, kontrolu ĉu la celata instanco funkcias kaj estas ligita al la adreso kaj pordo en la profilo. ss -lntp montras aŭskultantojn, kaj ilia manko estas la kutima klarigo. Fajromuro, kiu rifuzas anstataŭ forĵeti, produktas la saman mesaĝon ĉe la klienta flanko, tial vi kontrolas ambaŭ.

Kontrolu ankaŭ la adresan familion. Servo ligita al 127.0.0.1 aŭ nur al IPv6 rifuzos klienton, kiu solviĝas al la alia.

Poste legu la servilan protokolon anstataŭ diveni. Restartigo post CA-prizorgado povas fiaski pro nelegebla aŭ mankanta dosiero kaj neniam atingi la aŭskultan staton, kaj la protokolo nomas la dosieron. Tio estas starta fiasko, malsama eraro ol rifuzita atestilo.

UDP ne havas manpremon por rifuzi

OpenVPN super UDP ne establas konekton en la TCP-senco, do nenio estas rifuzebla ĉe connect. En Linux, eraro montrata de UDP-ingo povas veni de ICMP port-unreachable generita de pli frua datagramo. La manpaĝo udp(7) priskribas tiun nesinkronan konduton.

Tial UDP-kliento povas presi rifuzon dum la servila procezo funkcias sed ne estas ligita al la atendata adreso.

Kie CRL efektive kontroliĝas

La CRL estas konsultata dum la TLS-manpremo, post kiam la samtavolano prezentas sian atestilon, kaj nur se la servila agordo tion ebligas. La opcio crl-verify de OpenVPN montras al la dosiero, kaj malsukceso aperas en la servila protokolo kiel validiga eraro nomante la atestilon.

Revokita kliento do konektiĝas ĉe la transporta tavolo kaj poste malsukcesas en aŭtentigo. Sama servilo, sama pordo, tute alia mesaĝo.

Kontrolu la eldoniston kaj la validigajn datojn de la CRL kiam vi atingos tiun stadion. CRL subskribita de la malĝusta CA, aŭ unu kiu eksvalidiĝis antaŭ ol la kliento konektiĝis, produktas validigajn erarojn, kiuj havas nenion komunan kun la propra atestilo de la kliento.

Mallonga gvidilo por la sekva fojo

Unue konfirmu la transporton: aŭskultanto ĉeestas, ĝusta adresa familio, fajromuro ne rifuzas. Poste konfirmu, ke la servo atingis sian aŭskultan staton legante la startan protokolon. Nur tiam rigardu manpremajn erarojn por validigaj mesaĝoj. Tenu tiun ordon fiksa, ĉar ĉiu paŝo forigas tutan klason de kaŭzoj.

Notu la transporton, la solvitan celon, la pordon kaj la precizan erartekston. Reinstalo de la kliento detruas tiun pruvon kaj kutime ŝanĝas nenion.