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) определя обхвата на опцията; вашата процедура за премахване определя дали споделянето е наистина приемливо.