Статычны ключ ці TLS для сувязі OpenVPN паміж двума вузламі?

Дзве машыны, якія размаўляюць толькі адна з адной, могуць захаваць гэтую тапалогію і ўсё ж атрымаць узгодненыя ключы трафіку. Форма сеткі і рэжым абароны — незалежныя выбары, і менавіта іх змешванне прымушае людзей спрабаваць змяніць статычную таямніцу шляхам замены файла, пакуль абодва дэманы працягваюць працаваць. Замена файла ключа ў працуючай пары нічога не змяняе. Статычны рэжым, які OpenVPN 2.6 пазначае як састарэлы, трымае адзін ключ на ўвесь час існавання тунеля, таму файл на дыску і ключ у памяці зноў супадаюць толькі пасля перазапуску абодвух бакоў. Калі патрабуецца аўтаматычнае абнаўленне, рэжым абароны павінен змяніцца.

Што статычны рэжым не можа зрабіць

У рэжыме сакрэту абодва бакі падзяляюць загадзя агульны ключ, які непасрэдна шыфруе і аўтэнтыфікуе тунель. Рукапаціскання няма, таму няма механізму, каб любы бок прапанаваў новы ключавы матэрыял, даказаў асобу або аднавіўся пасля неадпаведнасці без умяшання аператара. Абедзве ўласцівасці вынікаюць з адсутнасці канала кіравання, а не з адсутнай опцыі, і ніякі сцяг канфігурацыі не дадае яго ў гэты рэжым.

У кіраўніцтве OpenVPN 2.6 ясна сказана, што ключ застаецца, пакуль не будзе створаны новы. Гэта прымальна для лабараторнай сувязі або фіксаванай пары прылад з дакументаванай працэдурай замены, і непрымальна там, дзе доўгажывучы сакрэт — рэальная рызыка. Замена файла не стварае новы ключ для працуючай пары; яна стварае двух бакоў, якія разыходзяцца. Таму замена файла дадае прастой, не дадаючы змены ключа.

Таксама няма паняцця асобы боку, акрамя валодання файлам. Любы, хто мае ключ, з’яўляецца бокам, і нішто ў тунелі не запісвае, які бок які, таму адкліканне — усё або нічога.

Пераход да TLS без перапраектавання сувязі

Рэжым TLS дадае канал кіравання, а разам з ім — магчымасць узгадняць ключы канала даных. У разгортванні «вузел — вузел» адзін бок бярэ ролю сервера, а другі — ролю кліента, але тапалогія застаецца сувяззю паміж двума бакамі: кожны бок ведае канчатковы пункт іншага, і ніякі пул або шматкарыстальніцкі сэрвіс не з’яўляецца. Ролі — дэталь рукапаціскання, а не новая архітэктура.

Дайце кожнай машыне ўласную асобу. Кожнаму боку патрэбны сертыфікат і прыватны ключ, якар даверу, які правярае іншы бок, і правіла праверкі боку, якое называе, каго чакаюць. Не выкарыстоўвайце прыватны ключ аднаго боку на другім, каб зэканоміць час; гэта ператварае дзве асобы ў адну і пазбаўляе магчымасці адклікаць любы бок асобна. Рэгістрацыя — месца, каб зрабіць гэта правільна, бо выпраўленне пазней азначае пераноўку сертыфікатаў.

Трымайце сеткавы дагавор нязменным, пакуль абарона змяняецца. Тыя ж адрасы тунеля, маршруты і дазволеныя сэрвісы павінны дзейнічаць да і пасля, каб збой падчас міграцыі быў праблемай абароны, а не замаскіраваным сюрпрызам маршрутызацыі. Запішыце адрасы і маршруты да змены; параўноўваць іх потым хутчэй, чым аднаўляць па памяці.

Некаторыя разгортванні таксама абараняюць канал кіравання ўласным статычным ключом, які не змяняецца разам з каналам даных. Гэты ключ ахоўвае рукапацісканне, а не карысную нагрузку, таму яго кампраметацыя выкрывае ўзгадненне, а не трафік. Захоўвайце яго асобна ад матэрыялу канала даных і прызначце дату замены, за якую адказвае пэўная асоба. Яго змена азначае перазапуск абодвух бакоў у складаваным акне, таму ён заслугоўвае запісу ў календары, а не ў памяці.

Хто што абнаўляе і калі

У рэжыме TLS абнаўленне кіруецца настроенымі лімітамі: інтэрвалам часу, колькасцю байтаў або колькасцю пакетаў. Задакументаванае кіраванне часам — гэта тое, на што спадзяюцца большасць разгортванняў, і меншае эфектыўнае значэнне паміж двума бакамі можа пачаць замену, таму павышэнне яго толькі з аднаго боку не стрымае падзею. Ліміты па аб’ёме існуюць таму, што загружаная сувязь можа вычарпаць ключ задоўга да таго, як гэта зробіць гадзіннік. Ні адзін ліміт не з’яўляецца праверкай стану, і ні адзін не скажа вам, што абнаўленне ўдалося.

Менавіта таму дыягнаставаць паўторнае пераўзгадненне па адным канфігурацыйным файле — памылкова. Прачытайце налады на абодвух баках, затым паглядзіце на пераход у журнале, а не выказвайце здагадку пра няспраўнасць. Абнаўленне, якое завяршаецца чыста, выглядае як кароткі ўсплеск трафіку канала кіравання, а не як раз’яднанне.

Трымайце аб’екты асобна ў галаве. Сертыфікат даказвае доўгатэрміновую асобу і замяняецца па графіку, які вы кантралюеце. Ключ канала даных абнаўляецца аўтаматычна, а асобны абмен аўтэнтыфікацыі, калі разгортванне яго патрабуе, ідзе за палітыкай уліковага запісу і можа патрабаваць уласных дамоўленасцяў для наступных абменаў.

Поўнае адключэнне абнаўлення, усталяваннем інтэрвалу ў нуль, не з’яўляецца выпраўленнем для шумнага журнала. Яно ператварае здаровую падзею жыццёвага цыклу ў пастаянны ключ, што вяртае вас да ўласцівасці, ад якой вы спрабавалі пазбавіцца.

Прыняцце змены

Будуйце новую канфігурацыю з падтрыманага прыкладу ўсталяванага выпуску, а не з састарэлага мінімальнага фрагмента, чые алгарытмы і шляхі да файлаў былі ўспадкаваныя з іншага месца. Узгадніце пераключэнне так, каб абодва бакі змяніліся разам, і трымайце зацверджаны шлях аднаўлення на выпадак, калі адзін бок не запусціцца. Апусціце сувязь наўмысна, а не чакайце збою, каб праверыць адкат. Адкат, які вы адпрацавалі, каштоўнейшы за адкат, які вы апісалі.

Праверце тры рэчы: пачатковая праверка асобы паспяховая, меркаваны паток праграмы працуе, і кіраванае абнаўленне адбываецца без страты трафіку. Затым прачытайце пераход у журнале наконт таго, што ён насамрэч даказвае: новы ідэнтыфікатар ключа азначае, што бакі завяршылі замену, а не што тунель перападключыўся. Разглядайце яго як доказ аднаго кроку і праверце лічыльнікі трафіку, перш чым назваць міграцыю завершанай.

Што хаваў бы абяцанне нулявога перапынку: збой, якога вы яшчэ не бачылі. Няўдалае абнаўленне, сертыфікат, які сканчаецца, або збой шляху ўсё яшчэ могуць парушыць сувязь, і нішто з гэтага не выключана чыстым прагонам тэстаў. Уласцівасць, дзеля якой варта праектаваць, вузейшая і карыснейшая: звычайная замена ключоў перастае быць ручной заменай файла.