Статични кључ или TLS за OpenVPN везу између два чвора?

Два рачунара која разговарају само један с другим могу да задрже ту топологију и ипак добију договорене кључеве за саобраћај. Облик мреже и режим заштите су независни избори, а управо њихово мешање наводи људе да покушају да ротирају статичну тајну заменом датотеке док оба демона настављају да раде. Замена датотеке кључа испод пара који ради не ротира ништа. Статични режим, који OpenVPN 2.6 означава као застарео, држи један кључ за цео животни век тунела, па се датотека на диску и кључ у меморији поново слажу тек након поновног покретања оба краја. Ако је аутоматска обнова услов, режим заштите мора да се промени.

Шта статични режим не може

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

OpenVPN 2.6 приручник изричито наводи да кључ остаје док се не генерише нови. То је прихватљиво за лабораторијску везу или фиксни пар уређаја са документованим поступком ротације, а неприхватљиво свуда где је дуготрајна тајна стварни ризик. Замена датотеке не ствара нови кључ за пар који ради; она ствара два чвора која се не слажу. Зато замена датотеке додаје прекид рада без додавања ротације.

Такође нема појма о идентитету чвора изван поседовања датотеке. Свако ко држи кључ је чвор, и ништа у тунелу не бележи која је страна која, па је опозив све или ништа.

Прелазак на TLS без редизајна везе

TLS режим додаје контролни канал, а с њим и могућност преговарања о кључевима податковног канала. У распореду тачка-до-тачке једна страна преузима улогу сервера, а друга улогу клијента, али топологија остаје веза између два чвора: свака страна зна крајњу тачку оне друге, и не појављује се никакав базен нити вишекорисничка услуга. Улоге су детаљ руковања, а не нова архитектура.

Дајте сваком рачунару сопствени идентитет. Свака страна треба сертификат и приватни кључ, сидро поверења које проверава другу страну, и правило провере чвора које именује кога се очекује. Не користите поново приватни кључ једног чвора на другом ради уштеде времена; то претвара два идентитета у један и уклања могућност да се било која страна опозове засебно. Упис је место где се то исправно решава, јер касније исправљање значи поновно издавање сертификата.

Држите мрежни уговор непромењеним док се заштита мења. Исте адресе тунела, руте и дозвољене услуге треба да важе пре и после, тако да квар током миграције буде проблем заштите, а не прерушено изненађење у рутирању. Запишите адресе и руте пре промене; њихово касније поређење је брже од реконструкције по сећању.

Нека постављања штите и контролни канал сопственим статичним кључем, који се не ротира са податковним каналом. Тај кључ чува руковање, а не корисни терет, па његов компромис излаже преговарање, а не саобраћај. Чувајте га одвојено од материјала податковног канала и дајте му датум замене који поседује именовано лице. Његова ротација значи поновно покретање оба чвора у координисаном прозору, зато заслужује запис у календару, а не у сећању.

Ко шта обнавља, и када

У TLS режиму обнова је вођена конфигурисаним ограничењима: временским интервалом, бројем бајтова или бројем пакета. Документована временска контрола је оно на шта се већина постављања ослања, а нижа ефективна вредност на два чвора може да покрене замену, па подизање само на једној страни неће задржати догађај. Ограничења по обиму постоје зато што заузета веза може да потроши кључ много пре него сат. Ниједно ограничење није провера здравља и ниједно вам не каже да је обнова успела.

Зато је дијагностиковање понављајућег поновног преговарања из једне конфигурацијске датотеке обмањујуће. Прочитајте поставке на оба чвора, па погледајте прелаз у дневнику уместо да претпоставите квар. Обнова која се чисто заврши изгледа као кратак излив саобраћаја контролног канала, а не као прекид везе.

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

Потпуно онемогућавање обнове постављањем интервала на нулу није решење за бучан дневник. Оно претвара здрав догађај животног циклуса у трајни кључ, што вас враћа на својство које сте покушавали да оставите за собом.

Прихватање промене

Изградите нову конфигурацију из подржаног примера инсталираног издања, а не из старог минималног исечка чији су алгоритми и путање датотека наслеђени однекуд другде. Ускладите пребацивање тако да се оба чвора промене заједно, и држите одобрену путању опоравка ако једна страна не успе да се подигне. Спустите везу намерно уместо да чекате прекид да бисте тестирали враћање. Враћање које сте увежбали вреди више од враћања које сте описали.

Тестирајте три ствари: почетна провера идентитета успева, предвиђени ток апликације ради, и контролисана обнова се догађа без губитка саобраћаја. Затим прочитајте прелаз у дневнику због онога што стварно доказује: нови идентификатор кључа значи да су чворови завршили замену, а не да се тунел поново повезао. Третирајте то као доказ једног корака, и проверите бројаче саобраћаја пре него што прогласите миграцију завршеном.

Оно што би обећање нултог прекида сакрило јесте квар који још нисте видели. Неуспешна обнова, сертификат који истиче или квар на путањи још увек могу да поремете везу, и ниједан од њих није искључен чистим тестним пролазом. Својство за које вреди пројектовати је уже и корисније: рутинска замена кључева престаје да буде ручна замена датотеке.