duplicate-cn gee twee toestelle een identiteit, nie twee nie

Kopieer die profiel na die tablet, maak konneksie, en die skootrekenaar val af. Voeg duplicate-cn by, albei bly verbind, en die probleem lyk opgelos totdat die twee toestelle om dieselfde tonneladres baklei of een verlore tablet die hele rekening vanlyn neem. Die opsie verander een ding en net een ding: of die bediener ’n tweede sessie toelaat onder ’n naam wat hy al gesien het. Alles wat mense verwag dat dit regmaak, van toestelonafhanklikheid tot per-toestel-adressering tot selektiewe herroeping, word steeds deur identiteit gedoen, en identiteit hier is die sertifikaat.

Die mite: ’n tweede sessie is ’n tweede identiteit

Die intuïsie is dat twee konneksies twee kliënte moet wees, en twee kliënte twee toestelle met hul eie regte. Die bediener modelleer dit nie so nie. Dit sien ’n gemeenskaplike naam, en met duplicate-cn geaktiveer aanvaar dit meer as een lewende sessie met daardie naam, elk met sy eie sessiestaat in die daemon.

Niks aan daardie aanvaarding raak sertifikaatverifikasie nie. Dieselfde sertifikaat is steeds die geloofsbrief, dieselfde sleutel is steeds die private sleutel, en enige beleid wat op die sertifikaatonderwerp gebaseer is, los nog steeds twee keer op dieselfde waarde op. ’n Tweede sessie is ’n tweede sok, nie ’n tweede identiteit nie.

Daardie onderskeid is onsigbaar terwyl alles werk. Dit word baie sigbaar die oomblik wanneer jy die twee toestelle van mekaar moet onderskei, wat gewoonlik die dag is wanneer een van hulle verlore raak.

Wat regtig verander wanneer twee sessies ’n naam deel

Sonder die opsie verskuif ’n nuwe konneksie onder ’n gemeenskaplike naam wat reeds verbind is, die vroeëre sessie. Dit is waarom die skootrekenaar afval wanneer die tablet konnekteer, en dit is ’n doelbewuste dubbelsinnigheidwagter, nie ’n fout nie. Met die opsie bly albei sessies lewendig en die bediener volg hulle afsonderlik per sessie, nie per toestel nie.

Elke sessie kry steeds sy eie buitenste konneksie en sy eie onderhandelde sleutels, so gelyktydige deurset is werklik gelyktydig. Wat hulle deel, is alles wat van die geloofsbrief afgelei word: beleidsoektogte, kliëntspesifieke konfigurasie, logboekidentiteit en herroeping. Sessiestaat behoort aan die konneksie en sterf daarmee, terwyl die feite op geloofsbriefvlak oor albei bly voortbestaan. Dit is waarom die statusuitset dieselfde naam twee keer kan lys terwyl die tellers afsonderlik bly.

Bevestig wat jou bou werklik doen voordat jy daarom ontwerp, want die opsie se effek word deur die opsie self bepaal en nie deur folklore nie:

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

Die statiese adres wat jy gedink het jy toegeken het

Per-kliënt-konfigurasie word by naam opgezoek, en dit is die lokval. ’n client-config-dir-lêer wat na die gemeenskaplike naam vernoem is is van toepassing op elke toestel wat daardie naam gebruik, so ’n ifconfig-push daarbinne gee albei toestelle dieselfde tonneladres. Die tweede sessie vestig óf nie óf bots op ’n manier wat soos ’n roeteringsfout lyk.

’n Dinamiese poel werk per ongeluk beter, want elke sessie kry onafhanklik ’n adres uit die poel. Dit gee jou steeds nie ’n stabiele adres per toestel nie, en dit gee jou beslis nie ’n per-toestel-beleid wat aan daardie adres gekoppel is nie.

As die ontplooiing username-as-common-name gebruik, word die opsoeksleutel die geauthentiseerde gebruikersnaam in plaas van die sertifikaatonderwerp, en dieselfde botsing volg vir enigiemand wat twee keer aanmeld. Die naam wat konfigurasie aandryf, moet uniek per toestel wees voordat per-toestel-konfigurasie iets beteken.

Wat ’n gedeelde identiteit nie by verwydering kan doen nie

Herroeping werk op die sertifikaat, nie op die vertoonnaam nie en nie op die sessie nie. Herroep daardie sertifikaat en elke toestel met ’n kopie verloor dadelik toegang, insluitend die een in die kantoor wat niemand wil steur nie. Hou dit en die verlore toestel bly werk, want niks in die protokol onderskei dit van die goedgekeurde kopie nie.

Logboeke erf dieselfde dubbelsinnigheid. Die statusuitset wys ’n gemeenskaplike naam en ’n werklike adres, en albei kan aan enige van die twee toestelle behoort. ’n Voorvalondersoek wat wil weet watter masjien wat gedoen het, kan die vraag nie uit die VPN se eie rekords beantwoord nie, maak nie saak hoeveel detail die logvlak gee nie.

Daar is geen kriptografiese oplossing hiervoor nie. Twee toestelle wat dieselfde sertifikaat aanbied, is vir die bediener dieselfde deelnemer twee keer, en enige skema wat anders voorgee, is ’n naamkonvensie eerder as ’n beheer.

Wanneer deel reg is, en hoe om dit te begrens

Deel het wettige gebruike: ’n laboratoriumrekening wat deur verskeie toetsmasjiene gebruik word, of ’n huishouding waar die toestelle saam bestuur word en herroepingsgranulariteit nie saak maak nie. In daardie gevalle, aktiveer die opsie doelbewus, hou die gedeelde geloofsbrief uit per-toestel-beleid, en gee die poel ruimte sodat sessies nie op ’n adres kan bots nie.

Vir enigiets wat afsonderlike adresse, afsonderlike logboeke of afsonderlike verwydering nodig het, reik afsonderlike sertifikate uit deur die normale inskrywingspad. Dit gee elke stroomaf-stelsel ’n afsonderlike objek om op te sleutel, en die opsie hou op om saak te maak omdat die name reeds uniek is.

Watter pad jy ook kies, toets die bestuursmodel eerder as die aanmelding. Verbind albei toestelle, bevestig dat hulle verskillende adresse het, simuleer dan ’n verlies en kyk of jy presies een van hulle kan verwyder. Die openvpn(8)-handleiding bepaal die omvang van die opsie; jou verwyderingsprosedure bepaal of deel in werklikheid aanvaarbaar is.