Mitä IPsec-ehdotukseen kuuluu? IKE- ja ESP-kentät

IKE käynnistyy, molemmat osapuolet mainostavat AES:ää, ja tunneli epäonnistuu silti virheeseen NO_PROPOSAL_CHOSEN. Loki nimeää ehdotuksen mutta ei kenttää, joka ei täsmännyt. Ehdotus on yksi täydellinen tarjous, ja yksi yhteensopimaton kenttä mitätöi koko yhdistelmän eikä vain sitä riviä. Sen lukeminen säkkinä itsenäisiä algoritmivalintoja on tavallinen syy siihen, että yhteensopimattomuus pysyy näkymättömänä.

Kaksi neuvottelua erillisillä ehdotuslistoilla

IKEv2 rakentaa kaksi tietoturvayhteyttä. Ensimmäinen on IKE SA, joka suojaa itse ohjausvaihdon, ja toinen on CHILD SA, joka kuljettaa liikenteesi ESP:n kautta. Kummallakin on oma ehdotuslistansa, ja osapuoli voi hyväksyä toisen ja hylätä toisen.

Tämä jako selittää yleisen hämmennysen: toimiva IKE SA todistaa vain, että ohjauskanavan algoritmit täsmäsivät. Jos CHILD-ehdotus epäonnistuu, tunneli ei kuljeta ainuttakaan pakettia, vaikka ensimmäinen vaihe on valmis ja lokit näyttävät ylhäältä terveiltä.

Järjestys kunkin listan sisällä on myös merkityksellinen. Vastaaja valitsee aloittajan järjestetyistä tarjouksista, joten laajasti yhteensopivan merkinnän siirtäminen kapean yläpuolelle muuttaa asennettavaa joukkoa ilman, että yksikään algoritmin nimi muuttuu. Kiinnitä tämä järjestys kokoonpanoon sen sijaan, että luottaisit oletuksiin. Vakaa järjestys tekee myös lokien vertailusta sivustojen välillä mielekästä.

Mitkä kentät kuuluvat mihinkin ehdotukseen

Kenttäjoukko on pieni, mutta se ei ole sama molemmissa neuvotteluissa. Lue taulukko rivi riviltä, koska yhden sarakkeen kenttä voi puuttua toisesta. Syntaksi vaihtelee toteutuksen mukaan; strongSwanin ehdotusdokumentaatio on yksi konkreettinen viite.

Salauskenttä nimeää salauksen ja useimmissa syntakseissa sen avainpituuden. Eheyskenttä nimeää tiivisteen, jolla salateksti todennetaan, ja PRF nimeää funktion, joka johtaa avainmateriaalin IKE SA:lle. DH-ryhmä luo tuoreen yhteisen salaisen materiaalin, minkä vuoksi se esiintyy molemmilla puolilla mutta eri tarkoituksiin.

Laajennetut järjestysnumerot kuuluvat vain datapolulle. Ne laajentavat järjestysavaruutta ja neuvotellaan osana CHILD-ehdotusta, joten yhteensopimattomuus siellä hylkää CHILD-tarjouksen jättäen IKE SA:n koskemattomaksi.

Miten yksi täydellinen tarjous valitaan

Jokainen ehdotus on joukko, ja vastaaja etsii joukkoa, jossa jokainen vaadittu kenttä on hyväksyttävä. Kaksi listaa voivat molemmat sisältää AES:n ja SHA-256:n eikä silti olla yhtään yhteensopivaa merkintää, koska avainpituus, PRF tai DH-ryhmä eroaa. Vertailu tehdään ehdotuksittain, ei algoritmeittain.

Kun mikään ei täsmää, vastaaja lähettää NO_PROPOSAL_CHOSEN sen SA-tyypin kanssa, joka epäonnistui. Lue, mihin ehdotuslistaan ilmoitus viittaa, ennen kuin muokkaat kokoonpanoa; ESP-algoritmien vaihtaminen IKE-ehdotuksen tultua hylätyksi tuhlaa yhden vianetsintäkierroksen.

Valintakäyttäytyminen kannattaa tuntea, kun virität profiilia. Jotkin toteutukset suosivat aloittajan järjestystä, toiset järjestävät uudelleen paikallisen käytännön mukaan, joten kahden toimittajan välillä toimiva joukko voi kadota kun käännät sen, kumpi puoli aloittaa yhteyden.

AEAD poistaa kentän sen sijaan, että lisäisi sellaisen

AES-GCM ja ChaCha20-Poly1305 todentavat ja salaavat yhdessä operaatiossa. Kun jompikumpi valitaan ESP:lle, eheysalgoritmista ei neuvotella erikseen, koska AEAD-rakenne kattaa sen jo. Siksi ehdotus, joka yhdistää AES-GCM:n SHA-256:een, on parhaimmillaan tarpeeton ja pahimmillaan hylätty.

PRF on edelleen erillinen IKE:n puolella, koska se johtaa avaimet ohjauskanavalle eikä suojaa hyötykuormia. Siksi IKE-ehdotus voi laillisesti yhdistää AEAD-salauksen, PRF:n ja DH-ryhmän, kun taas vastaava ESP-ehdotus luettelee vain AEAD-salauksen ja valinnaisen PFS-ryhmän.

Avainpituus on osa salausmerkkiä, joten AES-128-GCM ja AES-256-GCM ovat eri tarjouksia. Oppaasta kopioitu profiili, joka oletti 256-bit avaimet, ei täsmää 128-bit:lle konfiguroidun päätepisteen kanssa, vaikka molemmat rivit sanovat AES-GCM. Kaksi osapuolta voi sopia salausperheestä ja silti hylätä toisensa viivan jälkeisen luvun vuoksi.

Lue asennettu SA, älä kokoonpanoa

Konfiguroitu ehdotuslista on tarjous; asennettu SA on tulos. strongSwanissa ja Linux-ytimessä molemmat näkymät ovat saatavilla:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas tulostaa neuvotellut algoritmit SA-kohtaisesti, mukaan lukien sen, käyttääkö CHILD AEAD:ta. ip xfrm state näyttää, mitä ydin todella asensi, ja siinä on paikka vahvistaa, ettei avainten uusinta pudonnut eri joukkoon kuin dokumentoimasi.

Tallenna tämä tuloste kokoonpanon viereen korjauksen jälkeen. Kun asiakaspäivitys muuttaa oletuksiaan, tallennettu joukko antaa vertailupohjan, ja vertailu osoittaa kenttään, joka liikkui, sen sijaan että tutkinta aloitettaisiin alusta.