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