Шифры Windows и strongSwan: согласуйте нужный уровень

Обе стороны говорят AES-128, а туннель всё равно не поднимается. CBC и GCM — это разные преобразования, которые случайно имеют одинаковую длину ключа, и клиент, предлагающий одно, не удовлетворяет шлюз, принимающий только другое. Слово AES описывает семейство, а не договорённость.

Есть и вторая ось, и именно она порождает запутанные ошибки.

Два уровня, два независимых списка

IKE защищает сам обмен, а дочерняя ассоциация защищает трафик, который вам действительно важен. Windows показывает первое как метод шифрования и метод целостности, а второе как константы преобразования шифра и аутентификации. Эти поля не являются псевдонимами друг друга, и значение, допустимое в одном, может быть бессмысленным или неверным в другом. Если читать профиль с этим разделением в голове, большая часть путаницы исчезает.

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

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

Читайте ошибку рядом с предложениями

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Сравните полученное предложение, настроенное предложение и выбранное для этой единственной попытки. Здесь важны три разных списка, и только последний описывает то, что реально использовалось. Процитируйте его в заявке дословно, а не пересказывайте.

Держите CBC и GCM как отдельные альтернативы

Шлюзу, которому намеренно разрешено принимать любое из семейств, нужно два предложения, а не одно. В strongSwan запятая разделяет альтернативы, а дефис соединяет компоненты одного набора. Объединение обоих семейств дефисами даёт одно невозможное предложение вместо двух приемлемых.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

Предложение ESP — это не переименованное предложение IKE

Токен шифра выглядит одинаково в обоих списках, и почти ничего больше не переносится. В предложении ESP нет псевдослучайной функции обмена ключами, а его требования к целостности и прямой секретности обосновываются против политики Windows на другой стороне, а не копируются из строки IKE. Механический перенос одного списка в другой даёт нечто, что проходит проверку и никогда не согласуется.

Выберите направление и придерживайтесь его. Либо шлюз сохраняет политику только с GCM и клиент разворачивает полностью совместимую политику, либо шлюз принимает оба семейства и клиент сохраняет свой текущий набор. Включение запасного варианта, который запрещён политикой безопасности, не является исправлением, как бы быстро он ни убирал ошибку.

Проверьте оба набора, затем обновление ключа

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

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