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

Тунел што се крева и потоа се рестартира на секоја пола минута обично не е проблем на шифра или MTU. Тоа е еден идентитет што се користи двапати. Серверот гледа познато заедничко име, ја прифаќа новата сесија како најнова, и постариот уред открива дека е заменет. Од клиентската страна тоа изгледа како истек на неактивност и рестарт, затоа истрагата толку често почнува на погрешно место.

Почнете од интервалот на рестартирање

Интервалот е трага пред се друго. Рамномерен ритам што се совпаѓа со прозорецот ping-restart укажува на сесија што се заменува, а не на пат што откажува, бидејќи дефектите на патот ретко се толку правилни. Запишете го точниот размак меѓу рестартирањата и редот со причина во клиентскиот дневник. Истекот проследен со рестарт раскажува друга приказна од неуспешно ракување.

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

Запишете го интервалот и причината. Двете се докази, и двете се евтини за собирање.

Прочитајте што рече серверот за второто најавување

На сервер што го контролирате, дневникот го наведува заедничкото име и покажува второ поврзување што пристигнува. Без duplicate-cn тоа пристигнување ја заменува постоечката сесија за истото име, и пораката обично го кажува тоа отворено. Со duplicate-cn двете сесии постојат заедно и симптомот се менува: клиентите остануваат поврзани, но делат еден сет поставки по клиент и една одлука за отповикување. Читајте ги двата записа заедно, бидејќи замената е видлива само во низа.

На хостинг услуга може да немате никаков серверски дневник. Тогаш трагата е времето: стабилен тунел што паѓа секогаш кога се поврзува друга машина, а во клиентскиот дневник нема ништо освен истекот.

Споредете ги блоковите на сертификатот и клучот во двата профила, не само името на далечинскиот домаќин. Копираните профили обично се разликуваат само по името на датотеката.

Одвојте го идентитетот на серверската страна

Издадете по еден сертификат за секој уред преку CA што потпишува за овој сервер. Со Easy-RSA тоа значи одделно клиентско име за секој уред, и профилот потоа се гради од тој сертификат и неговиот клуч. Заедничкото име станува идентитет на уредот, и тоа е токму она што му недостигаше на серверот. Именувајте ги по уредот, а не по лицето, за да замената создаде ново име.

Споделениот клуч на контролен канал е одделна работа. tls-crypt или tls-auth го штити контролен канал за секој клиент и е наменет за споделување. Тој не е идентитет на клиент, и неговата замена нема да поправи дупликан сертификат.

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

По поделбата одржувајте ги адресите и поставките усогласени

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

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

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

Повлечете го стариот идентитет како што треба

Отповикајте го сертификатот кога хардверот се повлекува или недостасува, наместо да го избришете профилот од старата машина. Отповикувањето создава нов CRL, и на серверот му треба таа датотека каде што покажува crl-verify. Со таа директива на место, отсутен или нечитлив CRL го тера серверот да го одбие секој клиент, затоа тестирајте една позната сметка по секое ажурирање.

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