duplicate-cn giver to enheder én identitet, ikke to

Kopiér profilen til tabletten, opret forbindelse, og laptop'en falder af. Tilføj duplicate-cn, begge bliver forbundet, og problemet ser løst ud, indtil de to enheder slås om den samme tunneladresse, eller en tabt tablet tager hele kontoen offline. Indstillingen ændrer én ting og kun én ting: om serveren tillader en anden session under et navn, den allerede har set. Alt, hvad folk forventer, den skal rette, fra enhedsuafhængighed over adressering pr. enhed til selektiv tilbagekaldelse, sker stadig via identitet, og identiteten her er certifikatet.

Myten: en anden session er en anden identitet

Intuitionen siger, at to forbindelser må være to klienter, og to klienter bør være to enheder med deres egne rettigheder. Serveren modellerer det ikke sådan. Den ser et fælles navn, og med duplicate-cn aktiveret accepterer den mere end én levende session med det navn, og hver får sin egen sessionstilstand i daemonen.

Intet ved den accept rører certifikatverifikationen. Det samme certifikat er stadig legitimationsoplysningen, den samme nøgle er stadig den private nøgle, og enhver politik, der er knyttet til certifikatets subjekt, giver stadig den samme værdi to gange. En anden session er en anden socket, ikke en anden identitet.

Den forskel er usynlig, så længe alt virker. Den bliver meget synlig i det øjeblik, hvor du skal skelne de to enheder, og det er normalt den dag, en af dem går tabt.

Hvad ændrer sig egentlig, når to sessioner deler et navn

Uden indstillingen fortrænger en ny forbindelse under et fælles navn, der allerede er forbundet, den tidligere session. Det er derfor, laptop'en falder af, når tabletten opretter forbindelse, og det er en bevidst beskyttelse mod tvetydighed, ikke en fejl. Med indstillingen holder begge sessioner liv, og serveren sporer dem separat pr. session, ikke pr. enhed.

Hver session får stadig sin egen ydre forbindelse og sine egne forhandlede nøgler, så samtidig gennemstrømning er virkelig samtidig. Det, de deler, er alt, der udledes af legitimationsoplysningen: politikopslag, klientspecifik konfiguration, logidentitet og tilbagekaldelse. Sessionstilstand hører til forbindelsen og dør med den, mens fakta på identifikationsniveau består for begge. Derfor kan statusoutputtet liste det samme navn to gange, mens tællerne forbliver adskilte.

Bekræft, hvad din build faktisk gør, før du designer ud fra det, for indstillingens virkning defineres af indstillingen selv og ikke af folkesagn:

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

Den statiske adresse, du troede, du havde tildelt

Konfiguration pr. klient slås op på navn, og det er fælden. En client-config-dir-fil opkaldt efter det fælles navn gælder for hver enhed, der bruger det navn, så en ifconfig-push indeni giver begge enheder den samme tunneladresse. Den anden session enten kan ikke etableres, eller også kolliderer den på en måde, der ligner en routingfejl.

En dynamisk pulje opfører sig bedre ved et tilfælde, fordi hver session tildeles en adresse fra puljen uafhængigt. Det giver dig stadig ikke en stabil adresse pr. enhed, og det giver bestemt ikke en politik pr. enhed knyttet til den adresse.

Hvis udrulningen bruger username-as-common-name, bliver opslagsnøglen det autentificerede brugernavn i stedet for certifikatets subjekt, og den samme kollision følger for enhver, der logger ind to gange. Det navn, der styrer konfigurationen, skal være unikt pr. enhed, for at konfiguration pr. enhed skal betyde noget.

Hvad en delt identitet ikke kan gøre ved fjernelse

Tilbagekaldelse virker på certifikatet, ikke på visningsnavnet og ikke på sessionen. Tilbagekald det certifikat, og hver enhed med en kopi mister adgangen på én gang, inklusive den på kontoret, som ingen vil forstyrre. Behold det, og den tabte enhed bliver ved med at virke, fordi intet i protokollen skelner den fra den godkendte kopi.

Logfiler arver den samme tvetydighed. Statusoutputtet viser et fælles navn og en rigtig adresse, og begge kan tilhøre hver af de to enheder. En hændelsesgennemgang, der skal vide, hvilken maskine der gjorde hvad, kan ikke besvare spørgsmålet ud fra VPN'ens egne registreringer, uanset hvor mange detaljer logniveauet giver.

Der er ingen kryptografisk omvej her. To enheder, der fremviser det samme certifikat, er for serveren den samme deltager to gange, og enhver ordning, der foregiver andet, er en navngivningskonvention og ikke en kontrol.

Hvornår deling er rigtigt, og hvordan man afgrænser det

Deling har legitime anvendelser: en labkonto, som flere testmaskiner bruger, eller en husstand, hvor enhederne administreres sammen, og tilbagekaldelsesgranulariteten ikke betyder noget. I de tilfælde skal du aktivere indstillingen bevidst, holde den delte legitimationsoplysning ude af politikken pr. enhed og give puljen plads, så sessionerne ikke kan kollidere på en adresse.

For alt, der kræver separate adresser, separate logfiler eller separat fjernelse, skal du udstede separate certifikater via den normale tilmeldingsvej. Det giver hvert efterfølgende system et særskilt objekt at bygge på, og indstillingen holder op med at betyde noget, fordi navnene allerede er unikke.

Uanset hvilken vej du vælger, skal du teste styringsmodellen og ikke login. Forbind begge enheder, bekræft, at de har forskellige adresser, simuler derefter et tab, og kontroller, at du kan fjerne præcis én af dem. Manualen openvpn(8) definerer indstillingens omfang; din fjernelsesprocedure definerer, om deling faktisk er acceptabel.