IKEv2 NO_PROPOSAL_CHOSEN: на якім этапе набор быў адхілены?

NO_PROPOSAL_CHOSEN у журнале вядзе людзей да папярэдне агульнага ключа, і памылка застаецца пасля змены. Гэта ніколі не было праблемай уліковых даных: суразмоўца адхіліў кожную прапанову для гэтага абмену, што ёсць сцвярджэнне пра алгарытмы, а не пра асобу. Першае карыснае пытанне не ў тым, які алгарытм правіць, а ў тым, які абмен быў адхілены. Адкажыце на гэта перад любым параўнаннем. Затым параўнайце поўны набор, які быў прапанаваны, з поўным наборам, які дазваляе суразмоўца.

Спачатку: які абмен быў адхілены

IKEv2 узгадняе два віды сувязі. IKE SA абараняе само ўзгадненне, а CHILD SA абараняе трафік. Кожны мае ўласны набор прапаноў, і кожны можа праваліцца з адным і тым жа апавяшчэннем. Адхіленне падчас першапачатковага ўзгаднення IKE і адхіленне падчас узгаднення CHILD патрабуюць розных выпраўленняў, і журнал звычайна называе абмен у радку ці двух вышэй за апавяшчэнне. Чытайце гэтыя два радкі разам, інакш вы зменіце няправільны спіс прапаноў.

Апавяшчэнне само не вызначае абмен. Радок вышэй называе SA, якое ўзгадняецца, і гэтае імя паказвае на спіс прапаноў для праверкі.

Параўноўвайце поўныя наборы, а не асобныя ключавыя словы

Прапанова — гэта камбінацыя: алгарытм шыфравання, цэласнасць або AEAD, група абмену ключоў і любая псеўдавыпадковая функцыя. Параўнанне толькі назвы шыфравання — звычайная памылка, бо два бакі могуць пагадзіцца на AES-256 і ўсё ж разыходзіцца ў SHA-1 супраць SHA-256. Запішыце прапанаваны і дазволены наборы побач на этапе збою, затым шукайце пустое перасячэнне.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Таксама праверце, што абедзве рэалізацыі падтрымліваюць тое, што вы наладзілі. Назва, скапіяваная з іншай платформы, можа выглядаць сінтаксічна знаёмай а сам плагін або рэалізацыя цалкам адсутнічае.

Набор IKE і набор ESP — розныя аб'екты

Праўка прапановы IKE не выправіць адхіленую прапанову CHILD, і адваротнае таксама праўда. У strongSwan гэта асобныя налады, прыкладна proposals = aes256-sha256-modp2048 для IKE SA і асобны спіс ESP для CHILD SA. Змяніце спіс, які адпавядае няўдаламу абмену, затым перачытайце журнал, а не мяркуйце, што выпраўленне спрацавала.

Для CHILD SA адпаведная налада — гэта спіс прапаноў ESP, а не IKE. Капіраванне радка IKE у яго стварае канфігурацыю, якая аналізуе і ўзгадняе няправільны аб'ект.

Працаздольны тунэль, які збойваецца пры абнаўленні ключа

Калі тунэль працаваў гадзіну, а затым збойваў, першапачатковае ўзгадненне не з'яўляецца праблемай. Абнаўленне ключа можа выклікаць іншыя ўмовы: розная група абмену ключоў пасля першага абмену, розніца тэрмінаў жыцця паміж бакамі або змененая палітыка адказніка. Захоўвайце адзнаку часу абнаўлення і ідэнтыфікатары сувязі з абодвух бакоў. Гэты ўзор патрабуе параўнання прапаноў пры абнаўленні, а не даўжэйшага тайм-аўту. Змена тайм-аўту хавае сімптом і пакідае неадпаведнасць на месцы.

ipsec statusall паказвае кожную сувязь і алгарытмы, якія фактычна ўзгоднены. Гэты вывад — найхутчэйшы спосаб пацвердзіць, які спіс выкарыстоўваўся, і ён аддзяляе памылку канфігурацыі ад састарэлага тунэлю, які ніколі не пераўзгадняўся.

ipsec statusall | grep -E "IKE:|ESP:"

Выберыце перасячэнне, затым пацвердзіце абедзве фазы

Няхай адміністратар выбера дакументаванае сучаснае перасячэнне, якое падтрымліваюць абодва бакі, і запіша яго. Не вырашайце памылку ўключэннем кожнага састарэлага алгарытму або адключэннем праверкі асобы, бо ні адно з гэтага не вынікае з адхілення. Пасля змены ўсталюйце новае злучэнне і затым прымусіце абнаўленне ключа. Адно першае злучэнне не даказвае, што шлях абнаўлення працуе.

Захоўвайце прынятую камбінацыю разам з версіямі прашыўкі. Калі наступная памылка тычыцца селектараў трафіку, разглядайце яе асобна, бо згода пра крыптаграфію нічога не кажа пра тое, якія падсеткі абараняе тунэль. strongSwan дакументацыя прапаноў ахоплівае сінтаксіс абодвух спісаў.