Две устройства, един сертификат OpenVPN: цикълът на пресвързване

Тунел, който се вдига и след това се рестартира на всеки половин минута, обикновено не е проблем на шифъра или на MTU. Това е една самоличност, използвана два пъти. Сървърът вижда познато общо име, приема новата сесия за най-новата и по-старото устройство открива, че е заменено. От страна на клиента това изглежда като таймаут за бездействие и рестарт, затова разследването толкова често започва на грешното място.

Започнете от интервала на рестартиране

Интервалът е улика преди всичко друго. Равномерен ритъм, който съвпада с прозореца ping-restart, сочи към заменявана сесия, а не към повреден път, защото отказите на пътя рядко са толкова регулярни. Запишете точната разлика между рестартите и реда с причината в клиентския журнал. Таймаут, последван от рестарт, разказва друга история от неуспешен ръкостиск.

Проверете кога са започнали рестартите спрямо второ устройство. Нов лаптоп, телефон или профил, копиран на резервна машина, са обичайните причини, и времето обикновено съвпада с деня, в който някой го е настроил.

Запишете интервала и причината. И двете са доказателства и и двете се събират евтино.

Прочетете какво каза сървърът за второто влизане

На сървър, който контролирате, журналът назовава общото име и показва второ свързване. Без duplicate-cn това свързване заменя съществуващата сесия за същото име и съобщението обикновено го казва направо. С duplicate-cn двете сесии съществуват заедно и симптомът се променя: клиентите остават свързани, но споделят един набор настройки за клиент и едно решение за отзоваване. Четете двата записа заедно, защото замяната се вижда само в последователност.

При хостинг услуга може да нямате никакъв сървърен журнал. Тогава уликата е времето: стабилен тунел, който пада всеки път, когато се свърже друга машина, и нищо в клиентския журнал освен таймаута.

Сравнете блоковете на сертификата и ключа в двата профила, не само отдалеченото име на хоста. Копираните профили обикновено се различават само по името на файла.

Разделете самоличността от страна на сървъра

Издайте един сертификат на устройство чрез CA, който подписва за този сървър. С Easy-RSA това означава отделно клиентско име за всяко устройство и профилът се изгражда от този сертификат и неговия ключ. Общото име става самоличност на устройството, което е точно онова, което липсваше на сървъра. Назовавайте ги по устройство, а не по човек, така че замяната да дава ново име.

Споделеният ключ на контролния канал е отделно нещо. tls-crypt или tls-auth защитава контролния канал за всеки клиент и е предназначен да се споделя. Той не е самоличност на клиента и замяната му няма да поправи дублиран сертификат.

Дръжте сертификата, ключа и всеки конфигурационен файл за клиент под едно и също общо име, иначе съответствието се чупи при следващата връзка. Несъответствие там създава клиент, който се удостоверява и след това не получава нищо.

Поддържайте адресите и настройките съгласувани след разделянето

Фиксираните адреси въвеждат втори начин за сблъсък. Ако сървърът ги задава чрез ifconfig-pool-persist или файл за клиент, тези записи все още сочат към старото име. Две устройства могат да получат един и същ адрес на тунела дори след като сертификатите са разделени, и тази повреда изглежда различно от първоначалния цикъл.

Обновете съответствието по същото време като сертификата, после свържете отново двете устройства и сравнете зададените им адреси. Дублиран адрес се проявява като прекъсваща загуба, а не като чисто пресвързване.

Предавайте настройките, които трябва да се различават за всяко устройство, чрез собствения файл на това устройство, а не чрез споделен шаблон. Споделеният шаблон също прави следващия дубликат по-труден за забелязване.

Оттеглете старата самоличност както трябва

Отзовете сертификата, когато хардуерът е изведен от употреба или изчезнал, вместо да изтривате профила от старата машина. Отзоваването създава нов CRL и сървърът се нуждае от този файл там, където сочи crl-verify. С тази директива включена, липсващ или нечетим CRL кара сървъра да отхвърля всеки клиент, затова тествайте един известен акаунт след всяка актуализация.

Поддържайте инвентар, който свързва всеки сертификат с човек или устройство, с дати на издаване и отзоваване. Този инвентар отговаря кой все още има достъп, без да се четат имена на файлове, и не позволява на следващия копиран профил да поднови цикъла.