Шифри на Windows и strongSwan: изберете правилния слой

Съвпадащата дължина на ключа не е съвместим набор. Отделете IKE политиката от ESP трансформациите и дръжте CBC и GCM в различни предложения.

И двете страни казват 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 и клиентът внедрява пълна съвместима политика, или шлюзът приема и двете семейства и клиентът запазва съществуващия си набор. Включването на резервен вариант, който политиката за сигурност забранява, не е решение, колкото и бързо да изчиства грешката.

Проверете двата набора, после смяната на ключ

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

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

Подобни статии