duplicate-cn jout twa apparaten ien identiteit, net twa

Kopiearje it profyl nei de tablet, ferbynzje, en de laptop falt fuort. Foegje duplicate-cn ta, beide bliuwe ferbûn, en it probleem liket oplost oant de twa apparaten fjochtsje om itselde tunneladres of in ferlern tablet it hiele akkount offline nimt. De opsje feroaret ien ding en mar ien ding: oft de tsjinner in twadde sesje tastiet ûnder in namme dy't er al sjoen hat. Alles wat minsken ferwachtsje dat it reparearret, fan apparaatûnôfhinklikens oant adressering per apparaat en selektive ynlûking, bart noch altyd troch identiteit, en identiteit is hjir it sertifikaat.

De myte: in twadde sesje is in twadde identiteit

De yntuysje is dat twa ferbiningen twa kliïnten wêze moatte, en twa kliïnten twa apparaten mei har eigen rjochten. De tsjinner modellearret it net sa. Hy sjocht in mienskiplike namme, en mei duplicate-cn ynskeakele akseptearret er mear as ien libbene sesje mei dy namme, elk krijt syn eigen sesjestatus yn de daemon.

Neat oan dy akseptaasje rekket de sertifikaatferifikaasje. Itselde sertifikaat is noch hieltyd de legitimasje, deselde kaai is noch hieltyd de priveekaai, en elk belied dat op it sertifikaatsubjekt basearre is, liedt noch hieltyd twa kear ta deselde wearde. In twadde sesje is in twadde socket, net in twadde identiteit.

Dat ferskil is ûnsichtber salang't alles wurket. It wurdt tige sichtber op it momint dat jo de twa apparaten útinoar hâlde moatte, en dat is meastentiids de dei dat ien fan beide ferlern giet.

Wat echt feroaret as twa sesjes in namme diele

Sûnder de opsje ferpleatst in nije ferbining ûnder in mienskiplike namme dy't al ferbûn is, de eardere sesje. Dêrom falt de laptop fuort as de tablet ferbynt, en it is in bewuste befeiliging tsjin dûbelsinnigens, gjin bug. Mei de opsje bliuwe beide sesjes libben en folget de tsjinner se apart per sesje, net per apparaat.

Elke sesje krijt noch hieltyd syn eigen bûtenferbining en syn eigen ûnderhannele kaaien, dus tagelykse trochstringsfliet is echt tagelyk. Wat se diele is alles wat fan de legitimasje ôflaat is: beliedssochopdrachten, kliïntspesifike konfiguraasje, logidentiteit en ynlûking. Sesjestatus heart by de ferbining en stjert dêrmei, wylst de feiten op legitimasjenivo foar beide bliuwe. Dêrom kin de statusútfier deselde namme twa kear listje wylst de tellers apart bliuwe.

Kontrolearje wat jo build eins docht foardat jo dêr op ûntwerpe, want it effekt fan de opsje wurdt bepaald troch de opsje sels en net troch folkloare:

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

It statyske adres dat jo tochten dat jo tawiisd hiene

Konfiguraasje per kliïnt wurdt op namme socht, en dat is de mûklaach. In client-config-dir-bestân neamd nei de mienskiplike namme jildt foar elk apparaat dat dy namme brûkt, dus in ifconfig-push deryn jout beide apparaten itselde tunneladres. De twadde sesje komt of net ta stân, of botst sa dat it op in routingflater liket.

In dynamyske pool docht it by tafal better, om't elke sesje selsstannich in adres út de pool krijt. Dat jout jo noch hieltyd gjin stabile adres per apparaat, en it jout jo wis gjin belied per apparaat ferbûn oan dat adres.

As de ynset username-as-common-name brûkt, wurdt de sykkaai de autentisearre brûkersnamme yn stee fan it sertifikaatsubjekt, en deselde botsing folget foar elkenien dy't twa kear oanmeldt. De namme dy't de konfiguraasje stjoert, moat per apparaat unyk wêze, wol konfiguraasje per apparaat eat betsjutte.

Wat in dielde identiteit by it fuortheljen net kin

Ynferlûking wurket op it sertifikaat, net op 'e werjûn namme en net op 'e sesje. Lûk dat sertifikaat yn en elk apparaat mei in kopy ferliest fuortendaliks tagong, ek dejinge yn it kantoar dêr't nimmen oan steure wol. Hâld it en it ferlerne apparaat bliuwt dwaande, want neat yn it protokol ûnderskiedt it fan 'e goedkarde kopy.

Logs ervje deselde dûbelsinnigens. De statusútfier toant in mienskiplike namme en in echt adres, en beide kinne by ien fan beide apparaten hearre. In ynsidintbesjoch dat witte moat hokker masine wat die, kin de fraach net beäntwurdzje út 'e eigen records fan it VPN, hoefolle detail oft it lognivo ek jout.

Der is gjin kryptografyske omwei hjirfoar. Twa apparaten dy't itselde sertifikaat presintearje, binne foar de tsjinner deselde dielnimmer twa kear, en elk skema dat oars beweart is in nammejouwingskonvinsje en gjin kontrôle.

Wannear't diele goed is, en hoe't jo it beheine

Diele hat legitime gebrûken: in laboratoariumakkount dat troch ferskate testmasines brûkt wurdt, of in húshâlding dêr't de apparaten tegearre beheard wurde en de ynlûkingsdetalje net útmakket. Skeakelje de opsje yn dy gefallen bewust yn, hâld de dielde legitimasje bûten it belied per apparaat, en jou de pool romte sadat sesjes net op in adres botse kinne.

Foar alles wat aparte adressen, aparte logs of in apart fuortheljen nedich hat, jou aparte sertifikaten út fia it normale registraasjepaard. Dat jout elk folgjend systeem in apart objekt om op te bouwen, en de opsje docht der net mear ta, om't de nammen al unyk binne.

Hokker paad jo ek kieze, test it behearmodel en net de oanmelding. Ferbynzje beide apparaten, befêstigje dat se ferskillende adressen hawwe, simulearje dan in ferlies en kontrolearje oft jo krekt ien fan beide fuorthelje kinne. De hânlieding openvpn(8) bepaalt it berik fan de opsje; jo fuorthelproseduere bepaalt oft diele eins akseptabel is.