Gvidlibro: enkonduki du OpenVPN-klientojn aparte

Du klientoj sur unu gastiganto sonas kiel ankoraŭ unu servila bloko kaj dua pordo. Ĝi fariĝas alia projekto, kiam vi listigos ĉion, kion kliento efektive posedas: aŭskultanton, tunelan pulon, identecon, fido-dosierojn, itinerojn kaj revokan horaron. Preterlasu unu el tiuj kaj la dua kliento kviete heredas pecon de la unua. Konstruu karton por ĉiu kliento kaj plenigu ĝin antaŭ ol la unua kliento konektiĝas.

Asignu kompletan rimedan karton por ĉiu kliento

Rezervu la tutan aron kune: publika pordo, tunela subreto, agorda vojo, protokola celo, nomo de la serva kazo kaj aparato. Nomado kiel grupo estas tio, kio malhelpas la klasikan kopion de funkcianta dosiero, kiu ankoraŭ enhavas la pulon aŭ interfacon de la unua kliento. La valoroj estas ekzemploj, ne rezervitaj pordoj, do kontrolu, kion la gastiganto jam uzas. Servo, kiu startas, ne estas la sama afero kiel kliento, kiu estas kompleta.

Tenu la karton apud la agordo kaj ĝisdatigu ĝin kiam ajn valoro ŝanĝiĝas. Dokumentaro, kiu malproksimiĝas de la realo, estas pli malbona ol neniu.

Tenu fidajn materialojn ene de ĉiu kliento

Aparta eldona aŭtoritato por ĉiu kliento faciligas pripensi la limon kaj tenas la subskriban ŝlosilon for de la gastiganto elmetita al la interreto. Komunigita radiko ankaŭ povas funkcii, sed komuna ankro ne igas du servojn unu membreca domajno. Decidu, kiujn ĉenojn ĉiu aŭskultanto akceptas kaj kiujn klientajn identecojn ĝi rajtigas, poste skribu ambaŭ. Ne senŝeligi atestilojn el ĉeno per provo kaj eraro ĝis io konektiĝas.

La propra privata ŝlosilo de la servilo apartenas al protektita dosiero por ĉiu kliento, ne al ŝablona dosierujo, kiu estas replikata kune kun la agordo.

Apartigu la retojn same kiel la procezojn

Du procezoj sur du pordoj ankoraŭ dividas gastiganton kaj enkursigan tabelon, se vi ne apartigas ilin. Konfirmu, kio aŭskultas, antaŭ ol fidi la dezajnon.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

La aŭskultanta kontrolo montras, kiu procezo posedas ĉiun publikan pordon, kaj la konfirmo montras, ĉu klienta atestilo ĉeniĝas al la intencita ankro. Neniu el la eligoj pruvas, ke la kliento de A ne povas atingi la subreton de B, do difinu fontan kaj celan politikon, revenajn itinerojn kaj ajnan intence dividitan servon. Retaj nomspacoj aŭ ujoj apartigas enkursigajn kuntekstojn kaj malpliigas hazardan miksadon, sed ili ne estas kompleta luanta limo per si mem. Elektu pli fortan izoligan mekanismon, kiam la minaca modelo postulas ĝin.

Liveru revokon antaŭ transdono

Atestila disfaldiĝo ne estas kompleta ĝis revoko havas liveran vojon. Kontrolu la eldonanton kaj validecan fenestron de la CRL kiel parton de la enkonduko.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

La CRL-kontrolo raportas, kiam la listo estis eldonita kaj kiam ĝi eksvalidiĝas, kaj la serva stato konfirmas, ke la kazo leganta ĝin funkcias. Refreŝigu la liston laŭ la horaro de la eldona politiko eĉ kiam nenio nova estis revokita, ĉar eksvalidiĝinta CRL povas rifuzi ĉiun klienton. Publikigu kompletan dosieron anstataŭ lasi legantojn renkonti partan skribon, kaj validigu la subskribon antaŭ disfaldiĝo. Registru, kiu posedas eldonadon, funkciadon de la finpunkto kaj emeritiĝon, por ke malŝalto de kliento A ne ĝenu B.

Poste rulu la akceptan paron: permesita kliento atingas sian propran servon, kaj legitimilo de A estas rifuzata de la aŭskultanto de B. Tio estas la limo esprimita kiel testo.