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 документацията за предложенията обхваща синтаксиса за двата списъка.