duplicate-cn им дава на два уреда еден идентитет, не два

Копирајте го профилот на таблетот, поврзете се, и лаптопот отпаѓа. Додадете duplicate-cn, двете остануваат поврзани, и проблемот изгледа решен — сè додека двата уреда не почнат да се караат за истата адреса на тунелот или изгубен таблет не го исклучи целиот профил од мрежата. Оваа опција менува една работа и само една: дали серверот дозволува втора сесија под име што веќе го видел. Сè што луѓето очекуваат да поправи — од независност на уредите преку адресирање по уред до селективно отповикување — сè уште се прави преку идентитет, а идентитетот овде е сертификатот.

Мит: втората сесија е втор идентитет

Интуицијата вели дека две врски мора да бидат два клиенти, а два клиенти треба да бидат два уреда со свои права. Серверот не го моделира така. Тој гледа заедничко име и, со вклучен duplicate-cn, прифаќа повеќе од една жива сесија со тоа име, и секоја добива своја состојба на сесија во демонот.

Ништо во тоа прифаќање не ја допира проверката на сертификатот. Истиот сертификат останува акредитивот, истиот клуч останува приватниот клуч, и секоја политика врзана за субјектот на сертификатот сè уште се разрешува двапати на истата вредност. Втората сесија е втор сокет, не втор идентитет.

Таа разлика е невидлива додека сè работи. Станува многу видлива во мигот кога треба да ги разликувате двата уреда, а тоа обично е денот кога еден од нив се губи.

Што навистина се менува кога две сесии делат име

Без опцијата, нова врска под заедничко име што е веќе поврзано ја истиснува претходната сесија. Затоа лаптопот отпаѓа кога таблетот се поврзува, и тоа е намерна заштита од двосмисленост, не грешка. Со опцијата, двете сесии остануваат живи и серверот ги следи одделно по сесија, не по уред.

Секоја сесија сè уште добива своја надворешна врска и свои договорени клучеви, така што паралелната пропусност е навистина паралелна. Она што го делат е сè што произлегува од акредитивот: пребарувања на политики, конфигурација специфична за клиентот, идентитет во дневниците и отповикување. Состојбата на сесијата припаѓа на врската и умира со неа, додека фактите на ниво на акредитив остануваат за двете. Затоа излезот на состојбата може да го наведе истото име двапати, а бројачите да останат одделни.

Проверете што всушност прави вашата изградба пред да проектирате врз неа, зашто ефектот на опцијата го одредува самата опција, а не преданијата:

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

Статичната адреса за која мислевте дека сте ја доделиле

Конфигурацијата по клиент се бара по име, и тука е стапицата. Датотека client-config-dir именувана по заедничкото име се применува на секој уред што го користи тоа име, така што ifconfig-push во неа им дава на двата уреда иста адреса на тунелот. Втората сесија или не се воспоставува, или се судира така што изгледа како дефект во рутирањето.

Динамичен базен се однесува подобро случајно, зашто на секоја сесија и се доделува адреса од базенот независно. Тоа сè уште не ви дава стабилна адреса по уред, и сигурно не ви дава политика по уред врзана за таа адреса.

Ако распоредувањето користи username-as-common-name, клучот за пребарување станува автентификуваното корисничко име наместо субјектот на сертификатот, и истата колизија следи за секој што ќе се најави двапати. Името што ја води конфигурацијата мора да биде единствено по уред за конфигурацијата по уред да значи нешто.

Што не може заедничкиот идентитет при отстранување

Отповикувањето дејствува на сертификатот, не на прикажаното име и не на сесијата. Отповикајте го тој сертификат и секој уред што држи копија веднаш губи пристап, вклучително и оној во канцеларијата што никој не сака да го вознемири. Задржете го и изгубениот уред продолжува да работи, зашто ништо во протоколот не го разликува од одобрената копија.

Дневниците го наследуваат истото двосмисленост. Излезот на состојбата покажува заедничко име и вистинска адреса, и двете можат да припаѓаат на кој било од двата уреда. Прегледот на инцидент што треба да знае која машина што направила не може да одговори на тоа прашање од сопствените записи на VPN, колку и детали да дава нивото на дневникот.

Нема криптографски заобиколен пат за ова. Два уреда што го претставуваат истиот сертификат се, за серверот, истиот учесник двапати, и секоја шема што тврди поинаку е конвенција за именување, а не контрола.

Кога споделувањето е правилно и како да се ограничи

Споделувањето има легитимни употреби: лабораториски профил што го користат неколку тест машини, или домаќинство каде уредите се управуваат заедно и деталноста на отповикувањето не е важна. Во тие случаи вклучете ја опцијата намерно, држете го споделениот акредитив надвор од политиката по уред и дајте му простор на базенот за сесиите да не се судрат на адреса.

За сè што бара одделни адреси, одделни дневници или одделно отстранување, издајте одделни сертификати преку нормалниот пат за регистрација. Тоа му дава на секој следен систем посебен објект на кој да се потпре, и опцијата престанува да биде важна зашто имињата се веќе единствени.

Кој и да е патот што ќе го изберете, тестирајте го моделот на управување, а не најавувањето. Поврзете ги двата уреда, потврдете дека имаат различни адреси, потоа симулирајте загуба и проверете дали можете да отстраните точно еден од нив. Прирачникот openvpn(8) го определува опсегот на опцијата; вашата постапка за отстранување определува дали споделувањето е навистина прифатливо.