IKEv2 NO_PROPOSAL_CHOSEN: u kojoj fazi je skup odbijen?
Pronađite razmjenu koja je pala, pa uporedite cijeli ponuđeni i dozvoljeni skup. Promjena prethodno dijeljenog ključa ne može popraviti kriptografsku neusklađenost.
NO_PROPOSAL_CHOSEN u dnevniku šalje ljude ka prethodno dijeljenom ključu, a greška preživi i tu promjenu. Nikada nije bio problem u vjerodajnicama: sagovornik je odbio svaki predlog ponuđen za tu razmjenu, što je izjava o algoritmima, a ne o identitetu. Prvo korisno pitanje nije koji algoritam urediti, nego koja je razmjena odbijena. Odgovorite na to prije bilo kakvog poređenja. Zatim uporedite cijeli skup koji je ponuđen s cijelim skupom koji sagovornik dozvoljava.
Prvo: koja je razmjena odbijena
IKEv2 pregovara dvije vrste asocijacije. IKE SA štiti sam pregovor, a CHILD SA štiti saobraćaj. Svaka ima svoj skup predloga i svaka može pasti uz istu notifikaciju. Odbijanje tokom početnog IKE pregovora i odbijanje tokom CHILD pregovora traže različite popravke, a dnevnik obično navede razmjenu red ili dva iznad notifikacije. Čitajte ta dva reda zajedno, inače ćete urediti pogrešnu listu predloga.
Sama notifikacija ne identifikuje razmjenu. Red iznad nje navodi SA koji se pregovara, a to ime pokazuje na listu predloga koju treba pregledati.
Uporedite cijele skupove, ne pojedinačne ključne riječi
Predlog je kombinacija: algoritam šifrovanja, integritet ili AEAD, grupa za razmjenu ključeva i bilo koja pseudoslučajna funkcija. Poređenje samo naziva šifrovanja uobičajena je greška, jer se dva sagovornika mogu složiti oko AES-256 i dalje se ne slagati oko SHA-1 naspram SHA-256. Napišite ponuđeni i dozvoljeni skup jedan uz drugi u fazi koja je pala, pa tražite prazan presjek.
offered: aes256-sha256-modp2048
permitted: aes256-sha1-modp2048
Provjerite i da obje implementacije podržavaju ono što ste podesili. Ime prepisano s druge platforme može izgledati sintaksno poznato dok dodatak ili implementacija u potpunosti nedostaje.
IKE skup i ESP skup su različiti objekti
Uređivanje IKE predloga neće popraviti odbijeni CHILD predlog, a vrijedi i obratno. U strongSwan-u su to odvojene postavke, otprilike proposals = aes256-sha256-modp2048 za IKE SA i odvojena ESP lista za CHILD SA. Promijenite listu koja odgovara paloj razmjeni, pa ponovo pročitajte dnevnik umjesto da pretpostavite da je popravka uspjela.
Za CHILD SA relevantna postavka je ESP lista predloga, ne IKE lista. Kopiranje IKE reda u nju stvara konfiguraciju koja se parsira, ali pregovara pogrešan objekat.
Tunel koji radi, a padne pri rekey-u
Ako je tunel radio sat vremena i onda pao, početni pregovor nije problem. Rekey može ispitati druge uslove: drugu grupu za razmjenu ključeva nakon prve razmjene, neusklađenost lifetime-a između sagovornika ili promijenjenu politiku odgovarača. Sačuvajte vremensku oznaku obnove i identifikatore asocijacije s obje strane. Takav obrazac traži poređenje predloga pri obnovi, a ne duži timeout. Promjena timeouta skriva simptom i ostavlja neusklađenost na mjestu.
ipsec statusall prikazuje svaku asocijaciju i algoritme koji su zaista pregovarani. Taj izlaz je najbrži način da potvrdite koja je lista korištena i razdvaja grešku u konfiguraciji od zastarjelog tunela koji se nikad nije ponovo pregovarao.
ipsec statusall | grep -E "IKE:|ESP:"
Odaberite presjek, pa potvrdite obje faze
Neka administrator odabere dokumentovani moderni presjek koji oba sagovornika podržavaju i zapiše ga. Ne rješavajte grešku uključivanjem svakog zastarjelog algoritma niti isključivanjem provjere identiteta, jer ni jedno ne slijedi iz odbijanja. Nakon promjene uspostavite novu vezu, pa prisilno pokrenite rekey. Sama prva veza ne dokazuje da put obnove radi.
Sačuvajte prihvaćenu kombinaciju uz verzije firmvera. Ako se sljedeća greška tiče traffic selectora, tretirajte je odvojeno, jer dogovor o kriptografiji ne govori ništa o tome koje podmreže tunel štiti. strongSwan-ov dokumentacija o predlozima pokriva sintaksu za obje liste.