Ці можа спасылка OpenVPN са статычным ключом абслугоўваць некалькі кліентаў?
Рэжым статычнага ключа злучае двух партнёраў. Даданне client-to-client не ператворыць яго ў сервер з некалькімі кліентамі; для гэтага патрэбны рэжым TLS і асобная ідэнтычнасць кожнай прылады.
Рэжым статычнага ключа злучае роўна двух партнёраў, і гэта яго канструкцыя, а не абмежаванне, якое хтосьці забыўся зняць. 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 — адзіная ўстаноўка, у якой некалькі кліентаў сапраўды асобныя партнёры.
Калі журнал паказвае адно агульнае імя для кожнай прылады, праблема не ў рэжыме. Праблема ў працэсе рэгістрацыі.