Може ли OpenVPN врска со статичен клуч да опслужува повеќе клиенти?

Режимот со статичен клуч поврзува точно два рамноправни јазли и тоа е неговиот дизајн, а не ограничување што некој заборавил да го отстрани. client-to-client е опција за проследување во серверскиот режим, па неговото додавање во конфигурација --secret не менува ништо во тоа колку клиенти можат да се поврзат. Одлуката не е која ознака да се додаде, туку дали распоредувањето бара врска точка-до-точка или услуга за повеќе клиенти. Ако неколку уреди треба да се поврзуваат независно, режимот на заштита се менува и секој уред добива идентитет.

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

За што служи режимот со статичен клуч

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

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

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

Зошто client-to-client не е делот што недостига

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

Другата честа забуна се однесува на материјалот tls-crypt или tls-auth. TLS сервер може да го дели еден од тие клучеви меѓу сите клиенти, бидејќи го штити контролниот канал наместо да докажува кој е секој клиент. Споделениот клуч на контролниот канал во TLS режим е друг објект од споделениот статичен клуч за податоци, иако двата пристигнуваат како слични датотеки.

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

Изградба на серверот за повеќе клиенти

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

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

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

Потоа свесно одлучете ја политиката за проследување. client-to-client овозможува сообраќај меѓу клиентите во серверската патека во корисничкиот простор, што многу распоредувања го сакаат, а некои не смеат да го имаат. Тоа е прекинувач на политика, не механизам за идентитет, и треба да се вклучи затоа што дизајнот го бара, а не затоа што упатството го вклучило.

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

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

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

На крајот прочитајте го серверскиот режим од конфигурацијата што работи, а не од меморијата. Конфигурацијата со статичен клуч со дополнителни опции е сѐ уште врска точка-до-точка и правилниот TLS сервер е единствениот распоред во кој неколку клиенти се навистина одделни јазли.

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