IKEv2 NO_PROPOSAL_CHOSEN: mikä vaihe hylkäsi kokoonpanon?

NO_PROPOSAL_CHOSEN lokissa lähettää ihmiset jaettuun avaimeen, ja virhe säilyy muutoksen jälkeen. Se ei koskaan ollut tunnistetietojen ongelma: vastapuoli hylkäsi jokaisen tuolle vaihdolle tarjotun ehdotuksen, mikä on väite algoritmeista, ei identiteetistä. Ensimmäinen hyödyllinen kysymys ei ole, mitä algoritmia muokata, vaan mikä vaihto hylättiin. Vastaa siihen ennen kuin vertaat mitään. Vertaa sitten täyttä tarjottua kokoonpanoa täyteen kokoonpanoon, jonka vastapuoli sallii.

Ensin: mikä vaihto hylättiin

IKEv2 neuvottelee kahdenlaisia assosiaatioita. IKE SA suojaa itse neuvottelun ja CHILD SA suojaa liikenteen. Kummallakin on oma ehdotusjoukko, ja kumpikin voi epäonnistua samalla ilmoituksella. Hylkäys alkuperäisen IKE-neuvottelun aikana ja hylkäys CHILD-neuvottelun aikana vaativat erilaisia korjauksia, ja loki yleensä nimeää vaihdon riviä tai kahta ilmoituksen yläpuolella. Lue ne kaksi riviä yhdessä, tai muokkaat väärää ehdotusluetteloa.

Ilmoitus yksinään ei tunnista vaihtoa. Sen yläpuolella oleva rivi nimeää neuvoteltavan SA:n, ja tämä nimi osoittaa tarkistettavaan ehdotusluetteloon.

Vertaa täydellisiä kokoonpanoja, älä yksittäisiä avainsanoja

Ehdotus on yhdistelmä: salausalgoritmi, eheys tai AEAD, avaintenvaihtoryhmä ja mahdollinen näennäissatunnaisfunktio. Vain salauksen nimen vertaaminen on tavallinen virhe, koska kaksi vastapuolta voi sopia AES-256:sta ja silti olla eri mieltä SHA-1:stä vastaan SHA-256. Kirjoita tarjottu ja sallittu kokoonpano vierekkäin epäonnistuneessa vaiheessa ja etsi sitten tyhjä leikkaus.

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

Tarkista myös, että molemmat toteutukset tukevat sitä, mitä määritit. Toiselta alustalta kopioitu nimi voi näyttää syntaktisesti tutulta kun taas liitännäinen tai toteutus puuttuu kokonaan.

IKE-kokoonpano ja ESP-kokoonpano ovat eri objekteja

IKE-ehdotuksen muokkaaminen ei korjaa hylättyä CHILD-ehdotusta, ja päinvastoin. strongSwanissa nämä ovat erillisiä asetuksia, suunnilleen proposals = aes256-sha256-modp2048 IKE SA:lle ja erillinen ESP-luettelo CHILD SA:lle. Vaihda luetteloa, joka vastaa epäonnistunutta vaihtoa, ja lue sitten loki uudelleen sen sijaan, että olettaisit korjauksen toimineen.

CHILD SA:n osalta asiaankuuluva asetus on ESP-ehdotusluettelo, ei IKE-luettelo. IKE-rivin kopioiminen siihen tuottaa kokoonpanon, joka jäsennetään mutta neuvottelee väärän objektin.

Toimiva tunneli, joka epäonnistuu avaimen uusinnassa

Jos tunneli toimi tunnin ja epäonnistui sitten, alkuperäinen neuvottelu ei ole ongelma. Avaimen uusinta voi koetella muita ehtoja: eri avaintenvaihtoryhmä ensimmäisen vaihdon jälkeen, eliniän eroavuus vastapuolten välillä tai muuttunut vastaajan käytäntö. Säilytä uusinnan aikaleima ja assosiaation tunnisteet molemmilta puolilta. Tämä kaava vaatii ehdotusten vertailua uusinnassa, ei pidempää aikakatkaisua. Aikakatkaisun muutos kätkee oireen ja jättää eroavuuden paikoilleen.

ipsec statusall näyttää jokaisen assosiaation ja tosiasiassa neuvotellut algoritmit. Tämä tuloste on nopein tapa vahvistaa, mitä luetteloa käytettiin, ja se erottaa kokoonpanovirheen vanhentuneesta tunnelista, jota ei koskaan neuvoteltu uudelleen.

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

Valitse leikkaus ja vahvista sitten molemmat vaiheet

Anna järjestelmänvalvojan valita dokumentoitu nykyaikainen leikkaus, jota molemmat vastapuolet tukevat, ja kirjoita se muistiin. Älä ratkaise virhettä ottamalla käyttöön kaikkia vanhoja algoritmeja tai poistamalla identiteetin vahvistusta, koska kumpikaan ei seuraa hylkäyksestä. Muutoksen jälkeen muodosta uusi yhteys ja pakota sitten avaimen uusinta. Pelkkä ensimmäinen yhteys ei todista, että uusintapolku toimii.

Säilytä hyväksytty yhdistelmä laiteohjelmistoversioiden kanssa. Jos seuraava virhe koskee liikenteen valitsimia, käsittele se erikseen, sillä sopu salauksesta ei kerro mitään siitä, mitä aliverkkoja tunneli suojaa. strongSwanin ehdotusdokumentaatio kattaa molempien luetteloiden syntaksin.