Forpeli unu OpenVPN-klienton: kill, deny aŭ revoki atestilon?

Vi havas common name kaj adreson en viaj notoj, kaj tri komandojn, kiuj ĉiuj ŝajnas forigi klienton. Nur unu faras tion, kion vi volas, kaj la elekto dependas de tio, ĉu vi devas fini la nunan seancon, rifuzi la sekvan ensaluton aŭ tute forpreni la rajton konektiĝi. Legu la identecon, kiun vi vere havas, antaŭ ol tuŝi ion, ĉar OpenVPN-baseno poste donas la saman tunelan adreson al alia seanco.

Kiun identecon vi vere havas

Statusdosiero de versio 3 estas la kutima komencpunkto. La sekcio CLIENT_LIST portas la common name, la realan adreson, bajtajn nombrilojn kaj konektan tempon; la sekcio ROUTING TABLE mapigas virtualan adreson al common name kun tempindiko de la lasta referenco. La common name estas la stabila identeco. La virtuala adreso estas atribuo, kaj la reala adreso malantaŭ NAT povas ŝanĝiĝi inter seancoj, dum nenio sur la servilo ŝanĝiĝas.

La administra interfaco montras similan vidon per sia komando status kaj aldonas klientan ID por ĉiu seanco. Ĝuste tiun ID atendas client-kill, kaj ĝi ne estas la tunela adreso. Se vi bezonas scii, kiu common name ricevis kiun adreson ĉe la konektmomento, la medio de client-connect-skripto havas ambaŭ, kune kun la fidinda ekstera adreso, sed tiu skripto ruliĝas kiel OpenVPN-uzanto kaj bezonas skribeblan protokolan vojon.

Mortigu nun, rifuzu ĉe ensaluto, revoku por ĉiam

Ambaŭ forigaj komandoj en la administra interfaco estas seancoagoj. kill prenas common name aŭ realan adreson kaj pordon; client-kill prenas la klientan ID kaj tuj finas tiun ekzempleron. Neniu estas blokado: forpelita kliento kun valida atestilo kaj pasvorto rekonektiĝas en sekundoj, kio bonas kiam vi reciklas testan peer kaj senutilas kiam tekkomputilo estis ŝtelita.

client-deny estas alia speco de decido. Ĝi kutime eldoniĝas el aŭtentikiga aŭ client-connect-hoko kaj rifuzas la seancon kun kaŭzo, do ĝi taŭgas por politiko, kiu rifuzas ensaluton, ne por tiu, kiu interrompas konekton. La dokumentaro ankaŭ avertas, ke rifuzo eldonita dum TLS-renegocado malvalidigas la renegocitan ŝlosilon, dum la ekzistanta seanco povas daŭri ĝis la transira fenestro fermiĝas. Se la postulo estas, ke la kliento nun forestu, la dokumentita respondo estas client-kill.

Daŭra forigo kuŝas sub ĉio ĉi. Revoku la atestilon kaj certiĝu, ke crl-verify montras al listo, kiun la servilo vere reŝargas, malŝaltu la klient-specifan agordan dosieron en la ccd-dosierujo, aŭ malŝaltu la konton en tiu ajn backend, kiun la aŭtentikiga hoko pridemandas. Ankaŭ revoko ne estas tuja: kun la defaŭltaj agordoj de reneg-sec establita seanco povas daŭri ĝis ĝi renegocas, do la seanca ago kaj la akreditaĵa ago kompletigas unu la alian, ili ne estas alternativoj.

Ĉu la administra ingo estas libera?

La administra interfaco servas unu klienton samtempe. Se GUI aŭ monitora demono jam tenas la konekton, via skripto ne povas alkroĉiĝi apude, kaj depende de la kliento vi eble elpuŝas la ekzistantan anstataŭ malŝpari puran malsukceson. Ĝia pasvorto vojaĝas en klara teksto sur tiu ingo, do ĝi apartenas al loka adreso aŭ unix-ingo, neniam al publika interfaco.

Kiam vi ne povas preni la ingon, vi ankoraŭ havas opciojn, kaj ĉiuj estas pli malrapidaj. Unue lasu la sesion de la GUI, se vi kontrolas ĝin, aŭ akceptu la vojon tra la akreditaĵa tavolo kaj atendu la sekvan renegocadon. Kion vi ne devus fari, estas restartigi la servon por forigi unu klienton, ĉar tio ankaŭ finas ĉiujn aliajn seancojn kaj detruas la pruvojn de la statusdosiero por ĉi tiu.

La sinsekvo, kiun mi rulas sur viva servilo

Konektiĝu, legu la nunan staton, agu laŭ la ID, kiun vi ĵus legis, kaj poste relegu ĝin. Valoroj kopiitaj el dokumento estas la plej ofta maniero mortigi la malĝustan personon.

status                     # note the client ID and common name
client-kill 3              # end that session now
kill Test-Client           # alternative: by common name
status                     # confirm the session is gone

La nomo kaj la numero supre estas anstataŭiloj, kaj ID-oj estas reuzataj post kiam aliaj klientoj malkonektiĝas. Konfirmu, ke la vico mankas, antaŭ ol vi notos ion kiel faritan, kaj kontrolu, ke la nombro da konektitaj klientoj moviĝis je unu kaj ne je pluraj.

Konfirmu, ke ĝi restis for

Notu la common name, la tunelan adreson, la eksteran adreson kaj la minuton de la forigo. Se la sama common name reaperas minuton poste, la seanca ago funkciis kaj la akreditaĵa tavolo ne, kio estas tute alia riparo ol tiu de komando, kiu neniam ekvalidis.

Poste testu de la klienta flanko. Revokita atestilo devus malsukcesi ĉe la sekva manpremo; se ĝi ankoraŭ konektiĝas, la CRL tute ne legiĝas, kaj tio estas la trovajo, kiun indas raporti. Elektu la agon laŭ tio, kion vi devas fini, konfirmu per dua status, kaj ripari la akreditaĵan tavolon, kiam la respondo devas daŭri pli longe ol la seanco.