duplicate-cn aukerak bi gailuri identitate bat ematen die, ez bi
duplicate-cn aukerak bigarren saio paraleloa onartzen du izen komun baten pean. Ez du inoiz bigarren gailu-identitaterik, bigarren helbiderik edo bereizketa bereizirik sortzen.
Kopiatu profila tabletera, konektatu, eta eramangarria erori egiten da. Gehitu duplicate-cn, biak konektatuta jarraitzen dute, eta arazoa konponduta dirudi bi gailuak tunel-helbide beragatik borrokatzen hasi arte edo galdutako tableta batek kontu osoa lineaz kanpo uzten duen arte. Aukerak gauza bat eta bakarra aldatzen du: zerbitzariak dagoeneko ikusi duen izen baten pean bigarren saioa onartzen duen ala ez. Jendeak konponduko duela espero duen guztia — gailuen independentziatik hasi eta gailuko helbideratzeraino eta ezabaketa hautakorreraino — identitatearen bidez egiten da oraindik, eta identitatea hemen ziurtagiria da.
Mitoa: bigarren saioa bigarren identitatea da
Intuizioak dio bi konexio bi bezero izan behar direla, eta bi bezerok beren eskubideak dituzten bi gailu izan beharko luketela. Zerbitzariak ez du horrela modelatzen. Izen komun bat ikusten du, eta duplicate-cn gaituta dagoenean izen hori daraman saio bizirik bat baino gehiago onartzen du, eta bakoitzak bere saio-egoera jasotzen du daemonan.
Onarpen horrek ez dio ukitzen ziurtagiria egiaztatzeari. Ziurtagiri bera da kredentziala oraindik, gako bera da gako pribatua oraindik, eta ziurtagiriaren subjektuan oinarritutako edozein politikak balio berera ebazten du oraindik bi aldiz. Bigarren saioa bigarren socket bat da, ez bigarren identitatea.
Bereizketa hori ikusezina da dena ondo dabilen bitartean. Oso ikusgai bihurtzen da bi gailuak bereizi behar dituzun unean, eta hori, normalean, horietako bat galtzen den eguna izaten da.
Zer aldatzen da benetan bi saio izen bat partekatzen dutenean
Aukerarik gabe, jada konektatuta dagoen izen komun baten pean datorren konexio berriak aurreko saioa lekualdatzen du. Horregatik erortzen da eramangarria tableta konektatzen denean, eta anbiguotasunaren aurkako babes nahita egina da, ez akats bat. Aukerarekin, bi saioak bizirik mantentzen dira eta zerbitzariak bereiz jarraitzen ditu saioaren arabera, ez gailuaren arabera.
Saio bakoitzak bere kanpoko konexioa eta negoziatutako gako propioak ditu oraindik, beraz aldi bereko emaria benetan da aldi berekoa. Partekatzen dutena kredentzialetik eratorritako guztia da: politika-kontsultak, bezeroaren konfigurazio espezifikoa, erregistroen identitatea eta ezabaketa. Saio-egoera konexioarena da eta harekin hiltzen da, kredentzial mailako datuak bien artean irauten duten bitartean. Horregatik zerrenda dezake egoera-irteerak izen bera bi aldiz, kontagailuak bereizita dauden bitartean.
Egiaztatu zure konpilazioak benetan zer egiten duen horren gainean diseinatu aurretik, aukeraren eragina aukerak berak definitzen baitu, ahoz ahoko kontakizunek ez:
grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf
Esleitu zenuela uste zenuen helbide estatikoa
Bezero bakoitzeko konfigurazioa izenaren arabera bilatzen da, eta hor dago tranpa. Izen komunaren client-config-dir fitxategi bat izen hori erabiltzen duen gailu guztiei aplikatzen zaie, beraz barruko ifconfig-push batek bi gailuei tunel-helbide bera ematen die. Bigarren saioa ez da ezartzen, edo bideratze-akats baten antza duen talka egiten du.
Igerileku dinamikoak hobeto jokatzen du ustekabean, saio bakoitzari igerilekutik helbide bat modu independentean esleitzen zaiolako. Horrek ez dizu oraindik gailu bakoitzeko helbide egonkorrik ematen, eta are gutxiago helbide horri lotutako gailu bakoitzeko politikarik.
Inplementazioak username-as-common-name erabiltzen badu, bilaketa-gakoa autentifikatutako erabiltzaile-izena bihurtzen da ziurtagiriaren subjektuaren ordez, eta talka bera gertatzen zaio bi aldiz saioa hasten duen edonori. Konfigurazioa gidatzen duen izenak gailu bakoitzeko bakarra izan behar du, gailu bakoitzeko konfigurazioak zentzua izan dezan.
Partekatutako identitateak erretiratzeko garaian egin ezin duena
Ezabaketak ziurtagirian eragiten du, ez bistaratzen den izenean eta ez saioan. Ezeztatu ziurtagiri hori, eta kopia bat duen gailu guztiek aldi berean galtzen dute sarbidea, bulegoan dagoen eta inork molestatu nahi ez duen hura barne. Mantendu, eta galdutako gailuak lanean jarraitzen du, protokoloan ezerk ez baitu onartutako kopiatik bereizten.
Erregistroek anbiguotasun bera heredatzen dute. Egoera-irteerak izen komun bat eta benetako helbide bat erakusten ditu, eta biak bi gailuetako edozeinenak izan daitezke. Zein makinak zer egin zuen jakin behar duen gertaeren berrikuspen batek ezin du galdera horri VPNaren beraren erregistroetatik erantzun, erregistro-mailak zenbat xehetasun eman.
Horretarako ez dago irtenbide kriptografikorik. Ziurtagiri bera aurkezten duten bi gailu, zerbitzariarentzat, partaidea bera dira bi aldiz, eta kontrakoa dioen edozein eskema izendapen-konbentzio bat da, ez kontrol bat.
Noiz den egokia partekatzea, eta nola mugatu
Partekatzeak erabilera legitimoak ditu: hainbat proba-makinak erabiltzen duen laborategiko kontu bat, edo gailuak elkarrekin kudeatzen diren eta ezabaketaren xehetasunak axola ez duen etxebizitza bat. Kasu horietan, gaitu aukera nahita, eduki kredentzial partekatua gailu bakoitzeko politikatik kanpo, eta eman tarte igerilekuari saioek helbide batean talka egin ez dezaten.
Helbide bereiziak, erregistro bereiziak edo erretiratze bereizia behar duen edozertarako, eman ziurtagiri bereiziak erregistratzeko bide arruntetik. Horrek beheragoko sistema bakoitzari objektu desberdin bat ematen dio oinarritzat, eta aukerak garrantzia galtzen du izenak jada bakarrak direlako.
Aukeratu bidea edozein dela ere, probatu kudeaketa-eredua, ez saioa hastea. Konektatu bi gailuak, egiaztatu helbide desberdinak dituztela, gero simulatu galera bat eta egiaztatu horietako bat zehazki erretiratu dezakezula. openvpn(8) eskuliburua aukeraren irismena definitzen du; zure erretiratze-prozedurak definitzen du partekatzea benetan onargarria den.