duplicate-cn gjev to einingar éin identitet, ikkje to

Kopier profilen til nettbrettet, kople til, og den berbare maskina dett ut. Legg til duplicate-cn, begge blir verande tilkopla, og problemet ser løyst ut — heilt til dei to einingane slåst om same tunneladresse eller eit tapt nettbrett tek heile kontoen av nett. Dette valet endrar éin ting og berre éin: om tenaren lèt ein andre sesjon gå føre seg under eit namn han alt har sett. Alt folk ventar at det skal rette opp, frå eininguavhengigheit til adressering per eining og selektivt tilbakekall, går framleis føre seg gjennom identitet, og identiteten her er sertifikatet.

Myten: ein andre sesjon er ein andre identitet

Intuisjonen seier at to tilkoplingar må vere to klientar, og to klientar bør vere to einingar med eigne rettar. Tenaren modellerer det ikkje slik. Han ser eitt felles namn, og med duplicate-cn slått på tek han imot meir enn éin levande sesjon med det namnet, og kvar får sin eigen sesjonstilstand i daemonen.

Ingenting ved den mottakinga rører sertifikatkontrollen. Det same sertifikatet er framleis legitimasjonen, den same nøkkelen er framleis den private nøkkelen, og kvar politikk som byggjer på sertifikatsubjektet gjev framleis same verdien to gonger. Ein andre sesjon er ein andre socket, ikkje ein andre identitet.

Den skilnaden er usynleg så lenge alt verkar. Han blir svært synleg i det augneblinken du må skilje dei to einingane, og det er vanlegvis dagen då ei av dei blir borte.

Kva som eigentleg blir annleis når to sesjonar deler eit namn

Utan valet trengjer ei ny tilkopling under eit felles namn som alt er tilkopla, den tidlegare sesjonen til side. Det er grunnen til at den berbare maskina dett ut når nettbrettet koplar til, og det er eit medvite vern mot tvitydigheit, ikkje ein feil. Med valet held begge sesjonane seg levande, og tenaren følgjer dei kvar for seg per sesjon, ikkje per eining.

Kvar sesjon får framleis si eiga ytre tilkopling og sine eigne framforhandla nøklar, så samstundes gjennomstraum er verkeleg samstundes. Det dei deler, er alt som kjem ut av legitimasjonen: politikkopslag, klientspesifikk konfigurasjon, loggidentitet og tilbakekall. Sesjonstilstand høyrer til tilkoplinga og døyr med henne, medan fakta på legitimasjonsnivå blir verande for begge. Difor kan statusutskrifta liste same namnet to gonger medan teljarane held seg åtskilde.

Stadfest kva byggjet ditt faktisk gjer før du designar rundt det, for verknaden av valet blir avgjord av valet sjølv og ikkje av folkeminne:

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

Den statiske adressa du trudde du hadde tildelt

Konfigurasjon per klient blir slått opp på namn, og der ligg fella. Ei client-config-dir-fil kalla opp etter det felles namnet gjeld for kvar eining som nyttar det namnet, så ein ifconfig-push inne i henne gjev begge einingane same tunneladresse. Den andre sesjonen blir anten ikkje etablert, eller kolliderer på ein måte som ser ut som ein rutefeil.

Ein dynamisk pool oppfører seg betre ved eit høve, fordi kvar sesjon får tildelt ei adresse frå poolen uavhengig. Det gjev deg framleis ikkje ei stabil adresse per eining, og det gjev deg i alle fall ikkje ein politikk per eining knytt til den adressa.

Viss utrullinga nyttar username-as-common-name, blir oppslagsnøkkelen det autentiserte brukarnamnet i staden for sertifikatsubjektet, og den same kollisjonen følgjer for alle som loggar inn to gonger. Namnet som styrer konfigurasjonen må vere unikt per eining for at konfigurasjon per eining skal tyde noko.

Kva ein delt identitet ikkje kan gjere ved fjerning

Tilbakekall verkar på sertifikatet, ikkje på visingsnamnet og ikkje på sesjonen. Kalla tilbake det sertifikatet, og kvar eining med ein kopi mistar tilgangen på ein gong, også den på kontoret som ingen vil forstyrre. Hald på det, og den tapte eininga held fram med å verke, fordi ingenting i protokollen skil henne frå den godkjende kopien.

Loggane arvar den same tvitydigheita. Statusutskrifta viser eit felles namn og ei verkeleg adresse, og begge kan høyre til kvar av dei to einingane. Ei hendingseftersyn som må vite kva maskin som gjorde kva, kan ikkje svare på det spørsmålet ut frå tenaren sine eigne oppteikningar, same kor mange detaljar loggnivået gjev.

Det finst ingen kryptografisk omveg for dette. To einingar som legg fram same sertifikatet, er for tenaren den same deltakaren to gonger, og kvart opplegg som hevdar noko anna, er ein namnekonvensjon og ikkje ein kontroll.

Når deling er rett, og korleis ein grensar henne

Deling har legitime bruk: ein labkonto som fleire testmaskiner nyttar, eller ein heim der einingane blir styrte saman og finleiken i tilbakekallet ikkje spelar noko rolle. I slike tilfelle slår du på valet medvite, held den delte legitimasjonen utanfor politikken per eining, og gjev poolen rom så sesjonane ikkje kan kollidere på ei adresse.

For alt som treng åtskilde adresser, åtskilde loggar eller åtskild fjerning, gjev du ut åtskilde sertifikat gjennom den vanlege registreringsvegen. Det gjev kvart nedstraums system eit eige objekt å byggje på, og valet sluttar å ha noko å seie fordi namna alt er unike.

Kva veg du enn vel, prøv styringsmodellen og ikkje innlogginga. Kople til begge einingane, stadfest at dei har ulike adresser, simuler så eit tap og kontroller at du kan fjerne nøyaktig éi av dei. Handboka openvpn(8) definerer kor vidt valet går; fjerningsprosedyren din definerer om deling faktisk er akseptabelt.