duplicate-cn geeft twee apparaten één identiteit, niet twee

Kopieer het profiel naar de tablet, maak verbinding, en de laptop valt weg. Voeg duplicate-cn toe, beide blijven verbonden, en het probleem lijkt opgelost — tot de twee apparaten vechten om hetzelfde tunneladres of een verloren tablet het hele account offline haalt. De optie verandert één ding en maar één ding: of de server een tweede sessie toestaat onder een naam die hij al heeft gezien. Alles wat mensen hopen dat hij oplost, van apparaatonafhankelijkheid tot adressering per apparaat en selectieve intrekking, gebeurt nog steeds via identiteit, en identiteit is hier het certificaat.

De mythe: een tweede sessie is een tweede identiteit

De intuïtie zegt dat twee verbindingen twee clients moeten zijn, en twee clients zouden twee apparaten met eigen rechten moeten zijn. De server modelleert dat niet zo. Hij ziet één gemeenschappelijke naam en accepteert met duplicate-cn aan meer dan één levende sessie met die naam, elk met een eigen sessiestatus in de daemon.

Niets aan die acceptatie raakt de certificaatverificatie. Hetzelfde certificaat blijft de credential, dezelfde sleutel blijft de privésleutel, en elk beleid op basis van het certificaatonderwerp levert nog steeds twee keer dezelfde waarde op. Een tweede sessie is een tweede socket, geen tweede identiteit.

Dat onderscheid is onzichtbaar zolang alles werkt. Het wordt zeer zichtbaar op het moment dat je de twee apparaten uit elkaar moet houden, en dat is meestal de dag dat een van beide verloren gaat.

Wat er werkelijk verandert wanneer twee sessies een naam delen

Zonder de optie verdringt een nieuwe verbinding onder een gemeenschappelijke naam die al verbonden is de eerdere sessie. Daarom valt de laptop weg wanneer de tablet verbinding maakt, en dat is een bewuste bescherming tegen dubbelzinnigheid, geen bug. Met de optie blijven beide sessies leven en volgt de server ze apart per sessie, niet per apparaat.

Elke sessie krijgt nog steeds zijn eigen buitenverbinding en zijn eigen onderhandelde sleutels, dus gelijktijdige doorvoer is echt gelijktijdig. Wat ze delen is alles wat uit de credential voortkomt: beleidsopzoekingen, configuratie specifiek voor de client, identiteit in logboeken en intrekking. Sessiestatus hoort bij de verbinding en sterft ermee, terwijl de feiten op credentialniveau voor beide blijven bestaan. Daarom kan de statusuitvoer dezelfde naam twee keer vermelden terwijl de tellers gescheiden blijven.

Controleer wat je build werkelijk doet voordat je erop ontwerpt, want het effect van de optie wordt bepaald door de optie zelf en niet door overlevering:

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

Het statische adres waarvan je dacht dat je het had toegewezen

Configuratie per client wordt op naam opgezocht, en daar zit de valkuil. Een client-config-dir-bestand genoemd naar de gemeenschappelijke naam geldt voor elk apparaat dat die naam gebruikt, dus een ifconfig-push erin geeft beide apparaten hetzelfde tunneladres. De tweede sessie komt ofwel niet tot stand, ofwel botst op een manier die op een routeringsfout lijkt.

Een dynamische pool gedraagt zich bij toeval beter, omdat elke sessie onafhankelijk een adres uit de pool krijgt. Dat geeft je nog steeds geen stabiel adres per apparaat, en zeker geen beleid per apparaat dat aan dat adres gekoppeld is.

Als de uitrol username-as-common-name gebruikt, wordt de opzoeksleutel de geauthenticeerde gebruikersnaam in plaats van het certificaatonderwerp, en dezelfde botsing volgt voor iedereen die twee keer inlogt. De naam die de configuratie stuurt moet per apparaat uniek zijn, wil configuratie per apparaat iets betekenen.

Wat een gedeelde identiteit bij verwijdering niet kan

Intrekking werkt op het certificaat, niet op de weergegeven naam en niet op de sessie. Trek dat certificaat in en elk apparaat met een kopie verliest onmiddellijk toegang, inclusief dat op kantoor dat niemand wil storen. Houd het aan en het verloren apparaat blijft werken, omdat niets in het protocol het onderscheidt van de goedgekeurde kopie.

Logboeken erven dezelfde dubbelzinnigheid. De statusuitvoer toont één gemeenschappelijke naam en één echt adres, en beide kunnen bij elk van de twee apparaten horen. Een incidentonderzoek dat moet weten welke machine wat deed, kan die vraag niet beantwoorden uit de eigen administratie van de VPN, hoeveel detail het logniveau ook biedt.

Er is geen cryptografische omweg voor. Twee apparaten die hetzelfde certificaat presenteren zijn voor de server dezelfde deelnemer twee keer, en elk schema dat anders beweert is een naamgevingsconventie en geen controle.

Wanneer delen juist is, en hoe je het begrenst

Delen heeft legitieme toepassingen: een labaccount dat door meerdere testmachines wordt gebruikt, of een huishouden waar de apparaten samen worden beheerd en de fijnheid van intrekking niet uitmaakt. Schakel de optie in die gevallen bewust in, houd de gedeelde credential buiten het beleid per apparaat, en geef de pool ruimte zodat sessies niet op een adres kunnen botsen.

Voor alles wat afzonderlijke adressen, afzonderlijke logboeken of een afzonderlijke verwijdering nodig heeft, geef je afzonderlijke certificaten uit via het normale inschrijvingspad. Dat geeft elk volgend systeem een apart object om op te bouwen, en de optie doet er niet meer toe omdat de namen al uniek zijn.

Welke weg je ook kiest, test het beheermodel en niet de aanmelding. Verbind beide apparaten, bevestig dat ze verschillende adressen hebben, simuleer dan een verlies en controleer of je precies één van beide kunt verwijderen. De handleiding openvpn(8) bepaalt de reikwijdte van de optie; jouw verwijderingsprocedure bepaalt of delen werkelijk aanvaardbaar is.