IKEv2 NO_PROPOSAL_CHOSEN: ktorá fáza odmietla súpravu?

NO_PROPOSAL_CHOSEN v logu posiela ľudí k predzdieľanému kľúču a chyba prežije aj túto zmenu. Nikdy nešlo o problém s prihlasovacími údajmi: partner odmietol každý návrh ponúknutý pre túto výmenu, čo je výrok o algoritmoch, nie o identite. Prvá užitočná otázka nie je, ktorý algoritmus upraviť, ale ktorá výmena bola odmietnutá. Odpovedzte na to skôr, než čokoľvek porovnáte. Potom porovnajte celú ponúknutú súpravu s celou súpravou, ktorú partner povoľuje.

Najprv: ktorá výmena bola odmietnutá

IKEv2 vyjednáva dva druhy asociácie. IKE SA chráni samotné vyjednávanie a CHILD SA chráni prevádzku. Každá má vlastnú množinu návrhov a každá môže zlyhať s tou istou notifikáciou. Odmietnutie počas počiatočného vyjednávania IKE a odmietnutie počas vyjednávania CHILD vyžadujú rôzne opravy, a log zvyčajne pomenuje výmenu riadok alebo dva nad notifikáciou. Čítajte tieto dva riadky spolu, inak upravíte nesprávny zoznam návrhov.

Samotná notifikácia výmenu neidentifikuje. Riadok nad ňou pomenúva vyjednávanú SA a ten názov ukazuje na zoznam návrhov, ktorý treba preskúmať.

Porovnávajte celé súpravy, nie jednotlivé kľúčové slová

Návrh je kombinácia: šifrovací algoritmus, integrita alebo AEAD, skupina na výmenu kľúčov a akákoľvek pseudonáhodná funkcia. Porovnávanie iba názvu šifrovania je obvyklá chyba, pretože dvaja partneri sa môžu zhodnúť na AES-256 a stále sa rozchádzať v SHA-1 versus SHA-256. Zapíšte ponúknutú a povolenú súpravu vedľa seba v zlyhanej fáze a potom hľadajte prázdny prienik.

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

Skontrolujte tiež, že obe implementácie podporujú to, čo ste nastavili. Názov skopírovaný z inej platformy môže vyzerať syntakticky povedome zatiaľ čo plugin alebo implementácia úplne chýba.

Súprava IKE a súprava ESP sú rôzne objekty

Úprava návrhu IKE neopraví odmietnutý návrh CHILD a naopak to platí tiež. V strongSwane sú to samostatné nastavenia, približne proposals = aes256-sha256-modp2048 pre IKE SA a samostatný zoznam ESP pre CHILD SA. Zmeňte zoznam, ktorý zodpovedá zlyhanej výmene, a potom znova prečítajte log, namiesto toho, aby ste predpokladali, že oprava zabrala.

Pre CHILD SA je príslušným nastavením zoznam návrhov ESP, nie zoznam IKE. Skopírovanie riadka IKE doň vytvorí konfiguráciu, ktorá sa naparsuje, ale vyjedná nesprávny objekt.

Fungujúci tunel, ktorý zlyhá pri obnove kľúča

Ak tunel bežal hodinu a potom zlyhal, počiatočné vyjednávanie nie je problém. Obnova kľúča môže preveriť iné podmienky: inú skupinu na výmenu kľúčov po prvej výmene, nesúlad životnosti medzi partnermi alebo zmenenú politiku respondéra. Uchovajte časovú pečiatku obnovy a identifikátory asociácie z oboch strán. Taký vzor vyžaduje porovnanie návrhov pri obnove, nie dlhší timeout. Zmena timeoutu skryje príznak a nesúlad zostane.

ipsec statusall zobrazuje každú asociáciu a algoritmy, ktoré sa skutočne vyjednali. Tento výstup je najrýchlejší spôsob, ako potvrdiť, ktorý zoznam sa použil, a oddeľuje chybu konfigurácie od zastaraného tunela, ktorý sa nikdy znova nevyjednal.

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

Vyberte prienik a potom potvrďte obe fázy

Nechajte správcu vybrať dokumentovaný moderný prienik, ktorý podporujú obaja partneri, a zapísať ho. Nerozlišujte chybu zapnutím všetkých starých algoritmov ani vypnutím overovania identity, pretože ani jedno nevyplýva z odmietnutia. Po zmene nadviažte nové spojenie a potom vynúťte obnovu kľúča. Samotné prvé spojenie nedokazuje, že cesta obnovy funguje.

Uchovajte prijatú kombináciu spolu s verziami firmvéru. Ak sa ďalšia chyba týka traffic selektorov, riešte ju samostatne, pretože zhoda na kryptografii nič nehovorí o tom, ktoré podsiete tunel chráni. dokumentácia návrhov strongSwanu pokrýva syntax pre oba zoznamy.