IKEv2 NO_PROPOSAL_CHOSEN: ve které fázi byla sada odmítnuta?

NO_PROPOSAL_CHOSEN v logu posílá lidi k předsdílenému klíči a chyba přežije i tuto změnu. Nikdy nešlo o problém s přihlašovacími údaji: protějšek odmítl každý návrh nabídnutý pro tuto výměnu, což je výrok o algoritmech, ne o identitě. První užitečná otázka není, který algoritmus upravit, ale která výměna byla odmítnuta. Odpovězte na to dřív, než cokoli porovnáte. Potom porovnejte celou sadu, která byla nabídnuta, s celou sadou, kterou protějšek povoluje.

Nejprve: která výměna byla odmítnuta

IKEv2 vyjednává dva druhy asociace. IKE SA chrání samotné vyjednávání a CHILD SA chrání provoz. Každá má vlastní sadu návrhů a každá může selhat se stejnou notifikací. Odmítnutí při počátečním vyjednávání IKE a odmítnutí při vyjednávání CHILD vyžadují různé opravy a log obvykle pojmenuje výměnu o řádek či dva výše než notifikaci. Čtěte tyto dva řádky společně, jinak upravíte špatný seznam návrhů.

Samotná notifikace výměnu neidentifikuje. Řádek nad ní pojmenovává SA, o kterém se vyjednává, a to jméno ukazuje na seznam návrhů, který je třeba prozkoumat.

Porovnávejte celé sady, ne jednotlivá klíčová slova

Návrh je kombinace: šifrovací algoritmus, integrita nebo AEAD, skupina pro výměnu klíčů a případná pseudonáhodná funkce. Porovnávat jen název šifrování je obvyklá chyba, protože dva protějšky se mohou shodnout na AES-256 a přesto se rozcházet v SHA-1 versus SHA-256. Zapište nabízenou a povolenou sadu vedle sebe v selhané fázi a pak hledejte prázdný průnik.

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

Zkontrolujte také, že obě implementace podporují to, co jste nastavili. Název zkopírovaný z jiné platformy může vypadat syntakticky povědomě zatímco plugin nebo implementace zcela chybí.

Sada IKE a sada ESP jsou různé objekty

Úprava návrhu IKE neopraví odmítnutý návrh CHILD a naopak. V strongSwanu jde o samostatná nastavení, zhruba proposals = aes256-sha256-modp2048 pro IKE SA a samostatný seznam ESP pro CHILD SA. Změňte seznam, který odpovídá selhané výměně, a potom log znovu přečtěte, místo abyste předpokládali, že oprava zabrala.

Pro CHILD SA je příslušným nastavením seznam návrhů ESP, ne IKE. Zkopírování řádku IKE do něj vytvoří konfiguraci, která se naparsuje, ale vyjedná špatný objekt.

Funkční tunel, který selže při rekey

Pokud tunel běžel hodinu a pak selhal, počáteční vyjednávání není problém. Rekey může prověřit jiné podmínky: jinou skupinu pro výměnu klíčů po první výměně, nesoulad lifetime mezi protějšky nebo změněnou zásadu respondéra. Uchovejte časové razítko obnovy a identifikátory asociace z obou stran. Takový vzorec vyžaduje porovnání návrhů při obnově, ne delší timeout. Změna timeoutu skryje příznak a nesoulad zůstane.

ipsec statusall zobrazuje každou asociaci a algoritmy, které byly skutečně vyjednány. Tento výstup je nejrychlejší způsob, jak potvrdit, který seznam byl použit, a odděluje chybu konfigurace od zastaralého tunelu, který se nikdy znovu nevyjednal.

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

Vyberte průnik a potom potvrďte obě fáze

Nechte správce vybrat dokumentovaný moderní průnik, který oba protějšky podporují, a zapište jej. Neřešte chybu zapnutím všech starších algoritmů ani vypnutím ověřování identity, protože ani jedno z odmítnutí nevyplývá. Po změně navazte nové spojení a potom vynuťte rekey. Samotné první spojení nedokazuje, že cesta obnovy funguje.

Přijatou kombinaci uchovejte spolu s verzemi firmwaru. Pokud se další chyba týká traffic selektorů, řešte ji samostatně, protože shoda na kryptografii nic neříká o tom, které podsítě tunel chrání. dokumentace návrhů strongSwanu pokrývá syntaxi pro oba seznamy.