duplicate-cn gir to enheter én identitet, ikke to

Kopier profilen til nettbrettet, koble til, og laptopen faller ut. Legg til duplicate-cn, begge blir værende tilkoblet, og problemet ser løst ut — helt til de to enhetene krangler om samme tunneladresse eller et tapt nettbrett tar hele kontoen offline. Alternativet endrer én ting og bare én ting: om serveren tillater en andre økt under et navn den allerede har sett. Alt folk forventer at det skal fikse, fra enhetsuavhengighet til adressering per enhet og selektiv tilbakekalling, gjøres fortsatt via identitet, og identiteten her er sertifikatet.

Myten: en andre økt er en andre identitet

Intuisjonen sier at to tilkoblinger må være to klienter, og to klienter bør være to enheter med egne rettigheter. Serveren modellerer det ikke slik. Den ser et felles navn, og med duplicate-cn aktivert godtar den mer enn én levende økt med det navnet, og hver får sin egen økttilstand i daemonen.

Ingenting ved den godkjenningen berører sertifikatverifiseringen. Det samme sertifikatet er fortsatt legitimasjonen, den samme nøkkelen er fortsatt den private nøkkelen, og enhver policy knyttet til sertifikatets subjekt gir fortsatt samme verdi to ganger. En andre økt er en andre socket, ikke en andre identitet.

Den forskjellen er usynlig så lenge alt virker. Den blir svært synlig i det øyeblikket du må skille de to enhetene, og det er vanligvis dagen en av dem blir borte.

Hva som egentlig endres når to økter deler et navn

Uten alternativet fortrenger en ny tilkobling under et felles navn som allerede er tilkoblet, den tidligere økten. Det er derfor laptopen faller ut når nettbrettet kobler til, og det er en bevisst beskyttelse mot tvetydighet, ikke en feil. Med alternativet holder begge øktene seg levende, og serveren sporer dem separat per økt, ikke per enhet.

Hver økt får fortsatt sin egen ytre tilkobling og sine egne forhandlede nøkler, så samtidig gjennomstrømning er virkelig samtidig. Det de deler, er alt som utledes fra legitimasjonen: policyoppslag, klientspesifikk konfigurasjon, loggidentitet og tilbakekalling. Økttilstand tilhører tilkoblingen og dør med den, mens fakta på legitimasjonsnivå består for begge. Derfor kan statusutdata liste samme navn to ganger mens tellerne forblir atskilt.

Bekreft hva bygget ditt faktisk gjør før du designer rundt det, for alternativets virkning bestemmes av alternativet selv og ikke av folkesagn:

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

Den statiske adressen du trodde du hadde tildelt

Konfigurasjon per klient slås opp på navn, og der ligger fellen. En client-config-dir-fil oppkalt etter det felles navnet gjelder for hver enhet som bruker det navnet, så en ifconfig-push inni den gir begge enhetene samme tunneladresse. Den andre økten blir enten ikke etablert, eller kolliderer på en måte som ser ut som en rutingsfeil.

En dynamisk pool oppfører seg bedre ved en tilfeldighet, fordi hver økt tildeles en adresse fra poolen uavhengig. Det gir deg fortsatt ikke en stabil adresse per enhet, og det gir deg absolutt ikke en policy per enhet knyttet til den adressen.

Hvis utrullingen bruker username-as-common-name, blir oppslagsnøkkelen det autentiserte brukernavnet i stedet for sertifikatets subjekt, og samme kollisjon følger for alle som logger inn to ganger. Navnet som styrer konfigurasjonen må være unikt per enhet for at konfigurasjon per enhet skal bety noe.

Hva en delt identitet ikke kan gjøre ved fjerning

Tilbakekalling virker på sertifikatet, ikke på visningsnavnet og ikke på økten. Tilbakekall det sertifikatet, og hver enhet med en kopi mister tilgangen med én gang, også den på kontoret som ingen vil forstyrre. Behold det, og den tapte enheten fortsetter å virke, fordi ingenting i protokollen skiller den fra den godkjente kopien.

Loggene arver den samme tvetydigheten. Statusutdata viser et felles navn og en ekte adresse, og begge kan tilhøre hvilken som helst av de to enhetene. En hendelsesgjennomgang som må vite hvilken maskin som gjorde hva, kan ikke svare på spørsmålet ut fra VPN-ens egne registreringer, uansett hvor mange detaljer loggnivået gir.

Det finnes ingen kryptografisk omvei for dette. To enheter som legger fram samme sertifikat, er for serveren den samme deltakeren to ganger, og enhver ordning som hevder noe annet, er en navnekonvensjon og ikke en kontroll.

Når deling er riktig, og hvordan avgrense det

Deling har legitime bruksområder: en labkonto som flere testmaskiner bruker, eller en husholdning der enhetene administreres sammen og tilbakekallingsdetaljene ikke betyr noe. I slike tilfeller aktiverer du alternativet bevisst, holder den delte legitimasjonen utenfor policyen per enhet, og gir poolen rom slik at øktene ikke kan kollidere på en adresse.

For alt som trenger separate adresser, separate logger eller separat fjerning, utsteder du separate sertifikater via den vanlige registreringsveien. Det gir hvert nedstrøms system et eget objekt å bygge på, og alternativet slutter å bety noe fordi navnene allerede er unike.

Uansett hvilken vei du velger, test styringsmodellen og ikke innloggingen. Koble til begge enhetene, bekreft at de har forskjellige adresser, simuler deretter et tap og kontroller at du kan fjerne nøyaktig én av dem. Håndboken openvpn(8) definerer alternativets omfang; fjerningsprosedyren din definerer om deling faktisk er akseptabelt.