Готов ли е WireGuard за продукция? Отговорът не е в протокола

Хората питат дали WireGuard е готов за продукция, което звучи като въпрос за криптография, а всъщност е въпрос за вашата среда. Протоколът се преглежда от години; внедряването все още трябва да отговори дали мрежите ви пренасят транспорта му, кой записва и извежда устройства и кой кърпи пакета в двата края. Тези отговори се различават между два сървъра в един шкаф и хиляда лаптопа. Протоколът е един и същ в двата случая; операциите не са.

Въпросът зад въпроса

Обикновено хората искат да знаят дали могат да се ангажират с дизайн, който няма да ги постави в неудобно положение след шест месеца. Това е въпрос на внедряване с четири части и всяка част може да се провали независимо от другите. Добрите отговори на три от тях не компенсират четвъртата.

Старо предупреждение за предварителна версия е факт за тази версия, а не постоянен етикет върху всеки по-късен пакет. По същия начин нито един блог пост не може да обяви вашата конкретна комбинация от ядро, клиент, мрежа и персонал за готова. Работата е да направите комбинацията явна и да я проверите.

Отнасяйте се към готовността като към набор от порти, които или преминавате, или записвате като отворени. Това превръща спора в контролен списък с отговорници. Освен това прави отворените точки видими за всеки, който подписва, вместо да ги зарови в пилотен отчет.

Порта първа: пътят трябва да носи UDP

WireGuard пренася трафика си по UDP и документира, че не предоставя режим TCP или обфускация на трафика. Дизайн, който разчита трафикът да изглежда като обикновен уеб трафик или на смяна на порта, за да получи поведение на TCP, се гради върху предположение, което софтуерът не поддържа.

Затова първата порта е проучване, не тест на една машина. Изброете средите за достъп, в които потребителите ви наистина работят, след което проверете одобрения път по UDP във всяка от тях и решете какво се случва, когато той е недостъпен.

Връзка, която работи от офиса, не доказва нищо за хотелска мрежа, университетски файруол или мобилен оператор, който обработва UDP по различен начин. Именно тези среди са причината внедряванията за отдалечен достъп да се провалят след успешен пилот. Пилотът не беше грешен; той беше тесен. Разширяването му е портата.

Запишете и резервния вариант. Ако отговорът е, че няма резервен вариант, това е решение, което си струва да се заяви предварително, вместо да се открие по време на командировка.

Порта втора: някой трябва да притежава ключовете

Перите на WireGuard се удостоверяват с ключове, по една двойка на участник. Това е лесно за описание и взискателно в експлоатация, защото нищо в протокола не записва устройство, не следи кой държи кой ключ и не премахва достъп при загуба на лаптоп. Протоколът предполага, че ключовете вече са правилни, а коректността е нечия работа.

Назовете човека, който записва устройство, записа, който свързва публичен ключ с човек и устройство, и процедурата за премахване. Ако премахването зависи от това да помните къде са инсталирани копия на конфигурационен файл, процедурата не е завършена.

Изберете едно устройство по време на пилота и го изведете от употреба докрай. Това упражнение дава по-полезна информация от още един тест на свързаността, защото разкрива пропуските в записите ви.

Порта трета: пакетът се нуждае от поддържащ

WireGuard може да дойде като реализация в ядрото, като дистрибуционен пакет или като клиент в потребителското пространство и всеки има свой път за обновяване. Оперативният въпрос е кой от тях изпълнявате, откъде идва и кой прилага бюлетин за сигурност.

Използваме WireGuard не е инвентаризация. Тя не посочва пакета за кърпене, версията на шлюза или човека, който може да върне лоша актуализация.

Порта четвърта: приемете натоварването, а не ръкостискането

Критериите за приемане трябва да описват какво правят потребителите. Достигане до вътрешно приложение, разрешаване на частното му име, отказ до неразрешена дестинация и следване на определеното поведение, когато тунелът е спрян, са всички наблюдаеми, а успешното ръкостискане не е нито едно от тях.

Прекарайте тези проверки през промяна в мрежата, рестартиране на устройство и прозорец за поддръжка на шлюза, защото точно при тези преходи внедряванията се чупят.

Пазете доказателствата до критериите, включително локалното състояние, което ги е произвело:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Зеленият тест в тиха мрежа с един лаптоп е начално наблюдение. Той не е твърдение за надеждност и отнасянето към него като към такова е начинът, по който работещ дизайн става дизайн, на който се вярва.