Что делает предварительно разделённый ключ в IPsec, OpenVPN и WireGuard

Слова «предварительно разделённый ключ» встречаются в документации IPsec, OpenVPN и WireGuard, но обозначают три разных объекта. Один служит секретом аутентификации, другой защищает канал управления, третий добавляет материал в рукопожатие, у которого уже есть идентичности. Если считать их взаимозаменяемыми, соединение упадёт на этапе, которого никто не ждал. Прочитайте, что это поле делает в данном протоколе, прежде чем копировать в него значение.

Три протокола, три значения

Каждый протокол определяет задачу ключа в своей спецификации, и эти задачи не пересекаются. Секрет аутентификации доказывает, что два пира знают одно и то же значение. Ключ канала управления защищает последующее согласование. Дополнение к рукопожатию меняет расписание ключей, не меняя того, кто такие пиры.

Ни одна из этих ролей не аутентифицирует человека, и именно эта путаница отнимает больше всего времени. Предварительно разделённый ключ выдаётся устройствам или шлюзам до обмена, поэтому любой владелец выглядит для другой стороны одинаково. Это свойство полезно для связи между двумя маршрутизаторами по схеме «площадка — площадка» и опасно для службы удалённого доступа с поименованными сотрудниками. Держите учётные данные и криптографический секрет в разных столбцах документа, описывающего развёртывание.

IPsec и OpenVPN используют слово по-разному

IKEv2 может аутентифицировать пира предварительно разделённым секретом вместо сертификатов, и значение должно совпадать на обеих сторонах. Поскольку один и тот же секрет обычно задают для группы пиров, любой владелец может выдать себя за остальных, и обмен не получает прямой секретности от ключей идентичности, которых у него никогда не было.

Опции tls-auth и tls-crypt в OpenVPN прикрепляют статический ключ к каналу управления, добавляя подпись HMAC или шифруя само согласование. Этот ключ не является паролем пользователя и не заменяет сертификат клиента. Различать их важно при обновлении, когда смена пароля оставляет ключ канала управления нетронутым.

PSK в WireGuard добавляет, но не идентифицирует

У пиров WireGuard уже есть открытые и закрытые ключи Curve25519, и рукопожатие аутентифицирует эти идентичности. Необязательный предварительно разделённый ключ подмешивается в связующий ключ, добавляя симметричный материал поверх обмена открытыми ключами.

Сам по себе он не даёт ни идентичности, ни учётной записи, поэтому оператор не может отличить двух владельцев по их PSK. Обе стороны должны нести одно и то же значение, иначе рукопожатие сорвётся без полезного сообщения об ошибке. Поэтому ротацию нужно планировать сразу с двух сторон, а не как правку одного файла.

Проверьте распространение, ротацию и удаление

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

Текст в Base64 — не шифрование. Секрет, лежащий рядом с открытым сертификатом в одном каталоге, остаётся секретом в открытом виде.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

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

Запишите, какой секрет защищает какой этап, чтобы сброс пароля никогда не принимали за обновление криптографического ключа. Эта одна строка экономит час каждый раз, когда кто-то проверяет развёртывание.