Reŝanĝita kliento ankoraŭ konektiĝas: la listo neniam alvenis
Malŝargo estas enigo por atestila kontrolo, ne komando, kiu finas seancon. Komparu, kiel nova konekto kaj kuranta tunelo vidas la liston.
Malŝargo neniam eniras kurantan tunelon por forigi seancon. La listo estas enigo por atestila kontrolo kaj estas konsultata dum la interŝanĝo de la rega kanalo, kiu komencas TLS-seancon. Tiu sola fakto klarigas ambaŭ surprizojn: malŝargita kliento rekonektiĝas, ĉar la listo neniam atingis la kontrolanton, kaj ekzistanta seanco postvivas, ĉar neniu rekontrolis ion ajn.
Listo estas enigo, ne ago
Dum la starigo de seanco la servilo validigas la klientan atestilon kontraŭ siaj fidoankroj, kaj la malŝarga direktivo aldonas listan serĉon al tiu decido. La kontrolo okazas sur la servilo, do la kliento ne povas vidi, ke ĝia atestilo estis malŝargita, kaj daŭre proponas la saman. Profilo, kiu ankoraŭ konektiĝas, do pruvas nur, ke iu kontrolanto akceptis la ĉenon, ne ke malŝargo malsukcesis.
La listo mem estas subskribita objekto kun eldondato kaj venonta ĝisdatiga dato. Neniela listo, unu subskribita de alia aŭtoritato aŭ unu, kies venonta ĝisdatigo jam pasis, ne anstataŭas la nunan, kaj ĉu kaduka listo estas rifuzata aŭ silente akceptata dependas de la deplojo.
Nova konekto kontraŭ kuranta seanco
Malŝargo estas taksata kiam seanco stariĝas aŭ renegociiĝas, ne kontraŭ la datena kanalo ĉe ĉiu pakaĵo. Kliento, kiu jam konektiĝis, tenas trafikajn ŝlosilojn, do ĝi daŭre pasigas pakaĵojn post kiam ĝia atestilo aperas sur la listo. La implicita renegoca intervalo mezuriĝas en horoj, tial ĝisdatigita listo povas efiki por novuloj dum kuranta tunelo restas.
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
Tuja plenumo postulas intencan agon, ne nur la liston. Restartigo de la servo devigas ĉiun klienton rekonektiĝi, dum finigo de unu seanco per la administra interfaco lasas la aliajn netuŝitaj. Elektu unu por okazaĵo kaj notu, kiun vi uzis. La du opcioj havas malsaman efikradion, kaj tio estas la vera decido.
Liveru la dosieron, kiun la kontrolanto efektive legas
La listo devas esti generata el la registro de la aŭtoritato kaj poste kopiata al ĉiu maŝino, kiu kontrolas atestilojn. Generi ĝin sur la CA-gastiganto kaj neniam instali ĝin sur la servilo estas la plej ofta fuŝo, kaj ĝi aspektas ekzakte kiel difektita malŝarga funkcio.
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem
Du detaloj decidas, ĉu la dosiero efektive estas legata. Relativa vojo solviĝas rilate al la agorda dosierujo, do kopio lasita en la hejma dosierujo de operatoro eble neniam estos trovita. Kaj la demono kutime rezignas privilegiojn post lanĉo, do la plenumkonto bezonas serĉan permeson en ĉiu patra dosierujo kaj legan permeson sur la dosiero. Kontrolu ambaŭ per la plenumkonto anstataŭ per root, alie la testo pruvas la malĝustan aferon.
Sur systemd-gastigantoj malmoligita unuo ankaŭ povas kaŝi la vojon, per nurlega vido aŭ protektita sistema dosierujo. De interne de la servo tio ne distingiĝas de mankanta dosiero, do kontrolu la limigojn de la unuo antaŭ ol serĉi permesan eraron. Legu la unuan dosieron antaŭ ol kulpigi la reĝimon de la dosiero.
Konfirmu sur la servilo, ne sur la kliento
La servila protokolo nomas, kio okazis: malfermo de la listo, ŝargado de ĝi aŭ malsukcesa kontrolo kun la malŝargita seria numero. La kliento raportas nur ĝeneralan malsukceson de manpremo, tial klientaj protokoloj estas malbona loko por serĉi malŝargan decidon.
Kontrolu per freŝa provo el la malŝargita profilo kaj tiam haltu. Sukcesa konekto el tiu profilo estas la signalo por ekzameni la dosierovojon kaj la plenumkonton, ne por supozi, ke la listo estis malĝusta. Konservu tiun sukcesan provon kiel akceptan teston, kaj ne kalkulu rekonekton, kiun vi ne observis.
Kio malŝargas nenion
Forigi la profilon de tekkomputilo, forpreni la atestildosieron de la kliento aŭ diri al la uzanto ĉesi konektiĝi ŝanĝas nenion sur la servilo. La atestilo restas valida ĝis la aŭtoritato registras la malŝargon kaj la kontrolanto legas la rezultan liston.
Tial ankaŭ indas skribi la ĉenon: registru la malŝargon, generu kaj subskribu la liston, disdonu ekzakte tiun dosieron kaj konfirmu, ke la servo-konto povas legi ĝin. Ĉiu ĉenero estas mallonga, kaj ajna mankanta lasas malŝargitan klienton ĝoje konektiĝi. Kontrollisto kun kvar linioj superas supozon kun neniom.