Готов ли 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

Зелёный тест в тихой сети с одним ноутбуком — это начальное наблюдение. Это не утверждение о надёжности, и относиться к нему как к таковому — как раз тот путь, которым работающий дизайн становится дизайном, которому доверяют.