duplicate-cn donas al du aparatoj unu identecon, ne du

Kopiu la profilon al la tabuleto, konektiĝu, kaj la tekkomputilo falas. Aldonu duplicate-cn, ambaŭ restas konektitaj, kaj la problemo ŝajnas solvita, ĝis la du aparatoj kverelas pri la sama tunela adreso aŭ perdita tabuleto elitigas la tutan konton. La opcio ŝanĝas unu aferon kaj nur unu: ĉu la servilo permesas duan seancon sub nomo, kiun ĝi jam vidis. Ĉio, kion homoj atendas, ke ĝi riparu — de aparata sendependeco tra adresado por aparato ĝis selekta revoko — ankoraŭ okazas per identeco, kaj identeco ĉi tie estas la atestilo.

La mito: dua seanco estas dua identeco

La intuicio diras, ke du konektoj devas esti du klientoj, kaj du klientoj devus esti du aparatoj kun propraj rajtoj. La servilo ne tiel modelas tion. Ĝi vidas komunan nomon, kaj kun duplicate-cn ŝaltita ĝi akceptas pli ol unu vivan seancon portantan tiun nomon, kaj ĉiu ricevas sian propran seanstanon en la demono.

Nenio en tiu akcepto tuŝas atestilan kontroladon. La sama atestilo restas la legitimilo, la sama ŝlosilo restas la privata ŝlosilo, kaj iu ajn politiko ligita al la atestila subjekto ankoraŭ solviĝas al la sama valoro dufoje. Dua seanco estas dua poŝingo, ne dua identeco.

Tiu distingo estas nevidebla dum ĉio funkcias. Ĝi tre videblas en la momento, kiam vi devas distingi la du aparatojn, kio kutime estas la tago, kiam unu el ili perdiĝas.

Kio vere ŝanĝiĝas, kiam du seancoj kunhavas nomon

Sen la opcio, nova konekto sub komuna nomo, kiu jam estas konektita, delokigas la pli fruan seancon. Tial la tekkomputilo falas, kiam la tabuleto konektiĝas, kaj tio estas intenca gardo kontraŭ dubsenseco, ne cimo. Kun la opcio, ambaŭ seancoj restas vivaj kaj la servilo spuras ilin aparte laŭ seanco, ne laŭ aparato.

Ĉiu seanco ankoraŭ ricevas sian propran eksteran konekton kaj siajn proprajn intertraktitajn ŝlosilojn, do samtempa trairo vere estas samtempa. Kion ili kunhavas, estas ĉio derivita de la legitimilo: politikaj serĉoj, klient-specifa agordo, protokola identeco kaj revoko. Sea stato apartenas al la konekto kaj mortas kun ĝi, dum la faktoj ĉe la nivelo de la legitimilo daŭras por ambaŭ. Tial la statusa eligo povas listigi la saman nomon dufoje, dum la nombriloj restas apartaj.

Kontrolu, kion via konstruo fakte faras, antaŭ ol desegni ĉirkaŭ ĝi, ĉar la efikon de la opcio difinas la opcio mem, ne folkloro:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

La statika adreso, kiun vi pensis, ke vi atribuis

La agordo por ĉiu kliento estas serĉata laŭ nomo, kaj tie estas la kaptilo. Dosiero client-config-dir nomita laŭ la komuna nomo validas por ĉiu aparato uzanta tiun nomon, do ifconfig-push ene donas al ambaŭ aparatoj la saman tunelan adreson. La dua seanco aŭ ne establiĝas, aŭ kolizias tiel, ke ĝi aspektas kiel enkursiga fuŝo.

Dinamika provizo kondutas pli bone hazarde, ĉar al ĉiu seanco oni atribuas adreson el la provizo sendepende. Tio ankoraŭ ne donas al vi stabilan adreson por aparato, kaj certe ne donas politikon por aparato ligitan al tiu adreso.

Se la enkonduko uzas username-as-common-name, la serĉa ŝlosilo fariĝas la aŭtentigita uzantnomo anstataŭ la atestila subjekto, kaj la sama kolizio sekvas por iu ajn, kiu ensalutas dufoje. La nomo, kiu regas la agordon, devas esti unika por ĉiu aparato, por ke la agordo por aparato signifu ion.

Kion komuna identeco ne povas fari ĉe forigo

Revoko agas sur la atestilon, ne sur la montratan nomon kaj ne sur la seancon. Revoku tiun atestilon kaj ĉiu aparato havanta kopion tuj perdas aliron, inkluzive tiun en la oficejo, kiun neniu volas ĝeni. Konservu ĝin kaj la perdita aparato daŭre funkcias, ĉar nenio en la protokolo distingas ĝin de la aprobita kopio.

Protokoloj heredas la saman dubsensecon. La statusa eligo montras komunan nomon kaj realan adreson, kaj ambaŭ povas aparteni al iu ajn el la du aparatoj. Incidenta revizio, kiu devas scii, kiu maŝino faris kion, ne povas respondi tiun demandon el la propraj rikordoj de la VPN, kiom ajn da detaloj la protokola nivelo donas.

Ne ekzistas kriptografia ĉirkaŭvojo por tio. Du aparatoj, kiuj prezentas la saman atestilon, estas por la servilo la sama partoprenanto dufoje, kaj iu ajn skemo, kiu asertas alie, estas nomiga konvencio, ne regilo.

Kiam kunhavigo pravas, kaj kiel limigi ĝin

Kunhavigo havas legitimajn uzojn: laboratoria konto uzata de pluraj testaj maŝinoj, aŭ mastrumo, kie la aparatoj estas administrataj kune kaj la detalo de revoko ne gravas. En tiuj kazoj ŝaltu la opcion intence, tenu la kunhavatan legitimilon ekster la politiko por aparato, kaj donu al la provizo spacon, por ke seancoj ne koliziu sur adreso.

Por io ajn, kio bezonas apartajn adresojn, apartajn protokolojn aŭ apartan forigon, eldonu apartajn atestilojn per la normala registriĝa vojo. Tio donas al ĉiu malsupra sistemo apartan objekton, sur kiu baziĝi, kaj la opcio ĉesas gravi, ĉar la nomoj jam estas unikaj.

Kiun ajn vojon vi elektos, testu la administran modelon, ne la ensaluton. Konektu ambaŭ aparatojn, konfirmu, ke ili havas malsamajn adresojn, poste simulatu perdon kaj kontrolu, ĉu vi povas forigi precize unu el ili. La manlibro openvpn(8) difinas la amplekson de la opcio; via foriga proceduro difinas, ĉu kunhavigo estas fakte akceptebla.