duplicate-cn ger två enheter en identitet, inte två

Kopiera profilen till surfplattan, anslut, och laptopen faller bort. Lägg till duplicate-cn, båda förblir anslutna, och problemet verkar löst — tills de två enheterna slåss om samma tunneladress eller en borttappad surfplatta tar hela kontot offline. Alternativet ändrar en sak och bara en: om servern tillåter en andra session under ett namn den redan har sett. Allt folk förväntar sig att det ska fixa, från enhetsoberoende till adressering per enhet och selektiv återkallelse, sker fortfarande via identitet, och identiteten här är certifikatet.

Myten: en andra session är en andra identitet

Intuitionen säger att två anslutningar måste vara två klienter, och två klienter borde vara två enheter med egna rättigheter. Servern modellerar det inte så. Den ser ett gemensamt namn och accepterar med duplicate-cn aktiverat mer än en levande session med det namnet, och var och en får sitt eget sessionstillstånd i daemonen.

Ingenting i det accepterandet rör certifikatverifieringen. Samma certifikat är fortfarande legitimationen, samma nyckel är fortfarande den privata nyckeln, och varje policy knuten till certifikatets subjekt ger fortfarande samma värde två gånger. En andra session är en andra socket, inte en andra identitet.

Den skillnaden är osynlig så länge allt fungerar. Den blir mycket synlig i det ögonblick du måste skilja de två enheterna åt, och det är oftast dagen då en av dem tappas bort.

Vad som egentligen ändras när två sessioner delar ett namn

Utan alternativet tränger en ny anslutning under ett gemensamt namn som redan är anslutet undan den tidigare sessionen. Det är därför laptopen faller bort när surfplattan ansluter, och det är ett avsiktligt skydd mot tvetydighet, inte en bugg. Med alternativet hålls båda sessionerna vid liv och servern spårar dem separat per session, inte per enhet.

Varje session får fortfarande sin egen yttre anslutning och sina egna förhandlade nycklar, så samtidig genomströmning är verkligen samtidig. Det de delar är allt som härleds från legitimationen: policyuppslagningar, klientspecifik konfiguration, loggidentitet och återkallelse. Sessionstillstånd tillhör anslutningen och dör med den, medan fakta på legitimationsnivå består för båda. Därför kan statusutdata lista samma namn två gånger medan räknarna förblir åtskilda.

Bekräfta vad din byggnad faktiskt gör innan du designar runt det, för alternativets effekt bestäms av alternativet självt och inte av folktro:

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

Den statiska adressen du trodde att du hade tilldelat

Konfiguration per klient slås upp på namn, och där ligger fällan. En client-config-dir-fil uppkallad efter det gemensamma namnet gäller för varje enhet som använder det namnet, så en ifconfig-push inuti ger båda enheterna samma tunneladress. Den andra sessionen antingen upprättas inte eller kolliderar på ett sätt som ser ut som ett routingfel.

En dynamisk pool beter sig bättre av en slump, eftersom varje session tilldelas en adress från poolen oberoende. Det ger dig fortfarande ingen stabil adress per enhet, och det ger dig absolut ingen policy per enhet knuten till den adressen.

Om utrullningen använder username-as-common-name blir uppslagsnyckeln det autentiserade användarnamnet i stället för certifikatets subjekt, och samma kollision följer för alla som loggar in två gånger. Namnet som styr konfigurationen måste vara unikt per enhet för att konfiguration per enhet ska betyda något.

Vad en delad identitet inte kan göra vid borttagning

Återkallelse verkar på certifikatet, inte på visningsnamnet och inte på sessionen. Återkalla det certifikatet och varje enhet med en kopia förlorar åtkomsten på en gång, inklusive den på kontoret som ingen vill störa. Behåll det och den borttappade enheten fortsätter att fungera, eftersom ingenting i protokollet skiljer den från den godkända kopian.

Loggarna ärver samma tvetydighet. Statusutdata visar ett gemensamt namn och en verklig adress, och båda kan tillhöra vilken som helst av de två enheterna. En incidentgranskning som måste veta vilken maskin som gjorde vad kan inte svara på den frågan utifrån VPN:ets egna register, hur många detaljer loggnivån än ger.

Det finns ingen kryptografisk genväg för detta. Två enheter som presenterar samma certifikat är för servern samma deltagare två gånger, och varje upplägg som påstår något annat är en namnkonvention och inte en kontroll.

När delning är rätt, och hur man avgränsar den

Delning har legitima användningar: ett labbkonto som flera testmaskiner använder, eller ett hushåll där enheterna administreras tillsammans och återkallelsens detaljrikedom inte spelar roll. Aktivera alternativet medvetet i sådana fall, håll den delade legitimationen utanför policyn per enhet, och ge poolen utrymme så att sessioner inte kan kollidera på en adress.

För allt som behöver separata adresser, separata loggar eller separat borttagning, utfärda separata certifikat via den vanliga registreringsvägen. Det ger varje nedströms system ett eget objekt att bygga på, och alternativet slutar spela roll eftersom namnen redan är unika.

Vilken väg du än väljer, testa hanteringsmodellen och inte inloggningen. Anslut båda enheterna, bekräfta att de har olika adresser, simulera sedan en förlust och kontrollera att du kan ta bort exakt en av dem. Handboken openvpn(8) definierar alternativets omfattning; din borttagningsprocedur avgör om delning faktiskt är acceptabel.