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