Двете страни поддържат AES, и двете приемат SHA-256, а тунелът все още не се вдига. Предложението се провали на компонент, който никой не е сравнил, обикновено групата за обмен на ключове. Тази инструкция прочита действителния обмен, преди да промени нещо, прилага една ограничена политика и оставя връщане назад, което възстановява предишните параметри.

Прочетете отказа, преди да смените група

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

Отговорът обикновено е на страната на сървъра. Логът на strongSwan на подходящо ниво изброява предложението, получено от клиента, и предложението, което е конфигуриран да приема, а разликата между двата списъка посочва компонента, който се е провалил.

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

Запишете и двата списъка. Четири позиции на трансформации и една група са кратък списък и сравняването му ред по ред отнема по-малко време от всеки експеримент. Четири позиции се задържат лесно в погледа. Файл с логове — не.

Сравнете всяка трансформация, а не едно познато име

IKE предложението е набор от избори, които всички трябва да съвпаднат. Шифроването защитава преговорите, цялостта или PRF ги удостоверява, а групата Diffie-Hellman създава нов ключов материал. Предложение, което съвпада по първите две и се различава по третата, пак е неприемливо и за двете страни.

Двете полета на Windows, които тук се бъркат, принадлежат на различни фази. DHGroup се отнася за обмена на ключове по IKE, а PfsGroup — за дъщерната асоциация, която защитава трафика. Промяната на второто не може да поправи отказ в първото.

Имената на групите се различават между реализациите и това е отделен източник на объркване. strongSwan пише modp2048 и ecp256, докато Windows използва имена от изброяване като Group14 и ECP256, затова сравнението трябва да преведе, преди да сравни. Пазете бележка в две колони с двете имена. Тогава следващото несъответствие се класифицира за секунди.

TransformWindows parameterstrongSwan nameFailure it causes
EncryptionCipherTransformConstantsaes, aes256gcm and similarNo common proposal at all
Integrity or PRFAuthenticationTransformConstantssha256, sha512 and similarProposal rejected after encryption matches
Key-exchange groupDHGroupmodp2048, ecp256Exchange fails during key establishment
Child SA protectionPfsGroupesp proposal groupsTunnel negotiates, data association does not

Приложете една пълна и ограничена политика

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

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

Превключвателят -WhatIf преглежда локалната промяна и не прилага нищо. Това е полезно и същевременно е чест капан, защото прегледът доказва само, че параметрите са синтактично приемливи за локалния cmdlet. Той не казва нищо за това дали шлюзът ще приеме полученото предложение.

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

След това настройте страната на strongSwan към същия набор, преди да тествате. Съгласувана промяна от двете страни е единственият вариант, който се сближава; промяна от една страна и повторни опити дават лог, пълен със същия отказ.

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

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

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

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

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

Връщането назад е предишният набор параметри, а не разрешителен резервен вариант. Ако клиентът е предложил само слаба стара група, отговорът е да се подобри общата политика на клиента и сървъра, а не да се добави тази група към шлюза, където всеки бъдещ партньор може да преговаря надолу до нея.

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

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