IKEv2 NO_PROPOSAL_CHOSEN: melyik szakasz utasította el a készletet?

A NO_PROPOSAL_CHOSEN a naplóban az embereket a megosztott kulcshoz küldi, és a hiba túléli a változtatást. Soha nem hitelesítő adatok problémája volt: a partner elutasította az adott cseréhez felkínált összes javaslatot, ami az algoritmusokról szóló kijelentés, nem az identitásról. Az első hasznos kérdés nem az, melyik algoritmust kell szerkeszteni, hanem hogy melyik cserét utasították el. Válaszoljon erre, mielőtt bármit összehasonlít. Ezután hasonlítsa össze a felkínált teljes készletet a partner által engedélyezett teljes készlettel.

Először: melyik cserét utasították el

Az IKEv2 kétféle társítást tárgyal. Az IKE SA magát a tárgyalást védi, a CHILD SA pedig a forgalmat. Mindkettőnek saját javaslatkészlete van, és mindkettő ugyanazzal az értesítéssel meghiúsulhat. A kezdeti IKE-tárgyalás alatti elutasítás és a CHILD-tárgyalás alatti elutasítás különböző javításokat igényel, és a napló általában egy-két sorral az értesítés felett megnevezi a cserét. Olvassa együtt azt a két sort, különben rossz javaslatlistát szerkeszt.

Az értesítés önmagában nem azonosítja a cserét. A felette lévő sor megnevezi a tárgyalt SA-t, és ez a név a vizsgálandó javaslatlistára mutat.

Teljes készleteket hasonlítson össze, ne egyedi kulcsszavakat

A javaslat kombináció: titkosítási algoritmus, integritás vagy AEAD, kulcscsere-csoport és bármilyen pszeudo-véletlen függvény. Csak a titkosítás nevének összehasonlítása a szokásos hiba, mert két partner egyetérthet az AES-256-ban, és mégis vitatkozhat a SHA-1 kontra SHA-256 kérdésében. Írja fel a felkínált és engedélyezett készletet egymás mellé a sikertelen szakaszban, majd keresse az üres metszetet.

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

Azt is ellenőrizze, hogy mindkét implementáció támogatja-e azt, amit beállított. Egy másik platformról másolt név szintaktikailag ismerősnek tűnhet miközben a bővítmény vagy az implementáció teljesen hiányzik.

Az IKE-készlet és az ESP-készlet különböző objektumok

Az IKE-javaslat szerkesztése nem javítja az elutasított CHILD-javaslatot, és fordítva is igaz. A strongSwanban ezek külön beállítások, nagyjából proposals = aes256-sha256-modp2048 az IKE SA-hoz és külön ESP-lista a CHILD SA-hoz. Módosítsa a sikertelen cserének megfelelő listát, majd olvassa újra a naplót ahelyett, hogy feltételezné, a javítás működött.

A CHILD SA esetében a releváns beállítás az ESP-javaslatlista, nem az IKE-lista. Az IKE-sor belemásolása olyan konfigurációt hoz létre, amely elemződik, de a rossz objektumot tárgyalja.

Működő alagút, amely kulcsújításnál meghiúsul

Ha az alagút egy órán át működött, majd meghiúsult, a kezdeti tárgyalás nem a probléma. A kulcsújítás más feltételeket próbálhat: az első csere utáni eltérő kulcscsere-csoportot, az élettartam eltérését a partnerek között vagy a megváltozott válaszadói házirendet. Őrizze meg az újítás időbélyegét és a társítás-azonosítókat mindkét oldalról. Az ilyen minta újításkor javaslat-összehasonlítást igényel, nem hosszabb időtúllépést. Az időtúllépés módosítása elrejti a tünetet, és helyben hagyja az eltérést.

ipsec statusall megjeleníti az egyes társításokat és a ténylegesen tárgyalt algoritmusokat. Ez a kimenet a leggyorsabb módja annak megerősítésére, melyik listát használták, és elválasztja a konfigurációs hibát az elavult alagúttól, amelyet soha nem tárgyaltak újra.

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

Válasszon metszetet, majd erősítse meg mindkét fázist

Kérje meg az adminisztrátort, hogy válasszon egy dokumentált modern metszetet, amelyet mindkét partner támogat, és írja fel. Ne oldja meg a hibát az összes régi algoritmus engedélyezésével vagy az identitás-ellenőrzés kikapcsolásával, mert egyik sem következik az elutasításból. A változtatás után hozzon létre új kapcsolatot, majd kényszerítsen kulcsújítást. Az első kapcsolat önmagában nem bizonyítja, hogy az újítási útvonal működik.

Őrizze meg az elfogadott kombinációt a firmware-verziókkal együtt. Ha a következő hiba a forgalomválasztókra vonatkozik, kezelje külön, mert a kriptográfiáról való megegyezés semmit nem mond arról, mely alhálózatokat védi az alagút. A strongSwan javaslati dokumentációja mindkét lista szintaxisát lefedi.