Miksi IPsec-tunnelisi toimii ensimmäiseen CHILD SA -avaimen uusintaan asti
Liikennettä kuljettava tunneli todisti IKE-asetukset, ei uusinnassa käytettävää avaintenvaihtoa. Katso, mihin PFS-poikkeama piiloutuu ja miten se saadaan esiin.
Tunneli nousi, ping vastasi ja kaikki kuittasivat. Neljä tuntia myöhemmin istunto katkeaa, osapuolet kirjaavat ehdotus- tai avaintenvaihtovirheen, ja ensimmäinen oletus on, että verkossa muuttui jotain. Mikään ei muuttunut. Liikennettä kuljettava tunneli on todistanut, että kaksi osapuolta ovat yhtä mieltä siitä, miten autentikoidaan ja miten ensimmäistä ala-assosiaatiota suojataan, eikä se ole todistanut mitään avaintenvaihdosta, jota ne vaativat uusinnassa. Poikkeama istuu näiden kahden tapahtuman välisessä aukossa.
Yhdistetty ei tarkoita, että PFS-asetukset täsmäävät
IKEv2:ssa ensimmäinen ala-assosiaatio luodaan autentikointivaihdon aikana, ja sen avaimet johdetaan materiaalista, jonka IKE-assosiaatio on jo tuottanut. Erillistä Diffie-Hellman-vaihtoa ei tapahdu sille ala-assosiaatiolle, joten käytäntöä, joka vaatii sellaisen uusinnassa, ei testata käyttöönotossa.
Uusinta on eri vaihto. Kun ala-assosiaation avain uusitaan, osapuolet voivat tehdä tuoreen avaintenvaihdon ehdotuksissaan nimeämänsä ryhmän kanssa, ja se on ensimmäinen hetki, jolloin ryhmäasetuksia verrataan. Siksi kaksi eri mieltä olevaa osapuolta voivat autentikoida, asentaa ala-assosiaation ja välittää liikennettä ja sitten epäonnistua uusinnassa.
Mihin poikkeama piiloutuu ehdotusmerkkijonossa
strongSwanissa ryhmä liitetään ala-ehdotukseen, minkä vuoksi merkkijono kuten aes256gcm16-prfsha256-ecp256 näyttää salausvalinnalta mutta kantaa myös avaintenvaihtovaatimuksen. Osapuolella, joka tarjoaa vain aes256gcm16-prfsha256 ei ole tällaista vaatimusta, ja kahden listan salaukset kohtaavat, mutta vaihto ei.
Lue ala-ehdotus ja IKE-ehdotus erillisinä listoina. IKE-listassa näkyvä ryhmä ei kerro mitään ala-listasta, ja toisen muokkaaminen toista lukiessa on tavallinen tapa, jolla tämä jää huomaamatta.
Lue virhe, älä tiedostoa, jota muokkasit
Etsi notify, joka päätti vaihdon. Ala-avaimen uusinta, joka palauttaa ”ei hyväksyttävää ehdotusta”, osoittaa ehdotuslistoihin; uusintapyyntö, joka ei koskaan saa vastausta, osoittaa polkuun tai osapuoleen, joka lakkasi kuuntelemasta. Nämä kaksi tarvitsevat eri korjaukset, ja lokirivin sanamuoto erottaa ne.
Vahvista käynnissä oleva kokoonpano, älä levyllä olevaa. Tiedosto, joka on tallennettu mutta jota ei ladattu, tai yhteys, joka on luettu uudelleen toisesta include-tiedostosta, tuottaa poikkeaman, jota mikään näkyvän tiedoston muokkaus ei korjaa.
Kolme tapahtumaa, joita kaikkia kutsutaan avaimen uusinnaksi
IKE-assosiaation avaimen uusinta, IKE-uudelleenautentikointi ja ala-assosiaation avaimen uusinta ovat erillisiä toimintoja, joilla on erilliset ehdotussäännöt. Yhdessä niistä raportoitu virhe ei kerro muista suoraan mitään, ja logi, joka sekoittaa ne, luetaan yhdeksi toistuvaksi viaksi, vaikka niitä on kolme.
Huomioi, minkä tapahtuman osapuoli nimeää, ja tarkista sitten ehdotukset vain sille tapahtumalle. Muuta yhtä listaa, lataa uudelleen ja pakota sama tapahtuma uudestaan. Jos logi nimeää uudelleenautentikoinnin, IKE-ehdotus on se, joka pitää lukea. Jos se nimeää ala-avaimen uusinnan, ala-ehdotus kantaa sen ryhmän, jolla on merkitystä.
Uusinnan poistaminen käytöstä ei ole korjaus
Uusinta-ajan asettaminen nollaan vaimentaa vaihdon, joka epäonnistuu, ja tunneli säilyy sen jälkeen, kunnes se puretaan tai osapuoli käynnistetään uudelleen. Ostit pidemmän eliniän avaimen ja poikkeaman, joka kohtaa sinut uudelleen migraatiossa, auditoinnissa tai toimittajan päivityksessä. Sama koskee elinikiä, jotka on venytetty kauas yli sen käytännön, jota toinen osapuoli odottaa.
Kohdista sen sijaan ehdotukset. Valitse ryhmä, jonka molemmat osapuolet toteuttavat, laita se ala-ehdotukseen molemmissa päissä ja pidä uusintakäytäntö alueella, jota organisaatio todella vaatii.
Todista se vaihdolla, joka epäonnistui
Lyhennä ala-avaimen uusinta-aikaa huoltokatkossa, jotta tapahtuma tulee minuuteissa eikä tunneissa, tai käynnistä ala-avaimen uusinta käsin. Tarkkaile sitten onnistunutta uusintaa ja vahvista, että liikenne jatkuu sen läpi, koska uusi kättely, joka asentaa ala-assosiaation mutta pudottaa sovellusvirran on eri vika.
Palauta sen jälkeen normaali elinikä ja säilytä molemmat tapahtumatietueet, epäonnistunut ja onnistunut. Todiste, jonka haluat, on että yhteys selviää omasta elinkaarestaan, ei että se selvisi pingistä.