Mi kerül egy IPsec-javaslatba? IKE- és ESP-mezők

Az IKE elindul, mindkét fél hirdeti az AES-t, és az alagút mégis NO_PROPOSAL_CHOSEN hibával áll le. A napló megnevezi a javaslatot, de nem a mezőt, amely nem egyezett. A javaslat egyetlen teljes ajánlat, és egyetlen összeférhetetlen mező az egész kombinációt érvényteleníti, nem csak azt a sort. Zsákként, független algoritmusválasztások gyűjteményeként olvasni ez a szokásos oka annak, hogy az eltérés láthatatlan marad.

Két tárgyalás külön javaslatlistákkal

Az IKEv2 két biztonsági társulást épít. Az első az IKE SA, amely magát a vezérlőcserét védi, a második pedig a CHILD SA, amely az ESP-n keresztül szállítja a forgalmát. Mindkettőnek saját javaslatlistája van, és egy fél elfogadhatja az egyiket, miközben elutasítja a másikat.

Ez a szétválás magyarázza a gyakori zavart: egy működő IKE SA csak azt bizonyítja, hogy a vezérlőcsatorna algoritmusai egyeztek. Ha a CHILD javaslat meghiúsul, az alagút egyetlen csomagot sem szállít, hiába fejeződött be az első fázis, és hiába tűnnek egészségesnek a naplók a tetején.

Az egyes listákon belüli sorrend is számít. A válaszadó a kezdeményező rendezett ajánlatai közül választ, így egy széles körben kompatibilis bejegyzés egy szűk fölé mozgatása megváltoztatja, melyik készlet települ, anélkül hogy bármely algoritmusnév megváltozna. Rögzítse ezt a sorrendet a konfigurációban ahelyett, hogy az alapértékekre hagyatkozna. A stabil sorrend a telephelyek közötti naplóösszehasonlítást is értelmessé teszi.

Mely mezők melyik javaslathoz tartoznak

A mezőkészlet kicsi, de a két tárgyalásban nem azonos. Olvassa a táblázatot soronként, mert az egyik oszlop mezője hiányozhat a másikból. A szintaxis megvalósításonként változik; a strongSwan javaslatdokumentációja egy konkrét hivatkozás.

A titkosítási mező megnevezi a rejtjelezőt, és a legtöbb szintaxisban a kulcshosszát is. Az integritásmező megnevezi a rejtjelezett szöveg hitelesítéséhez használt hasht, a PRF pedig azt a függvényt, amely az IKE SA kulcsanyagát származtatja. A DH-csoport friss közös titkos anyagot hoz létre, ezért jelenik meg mindkét oldalon, de eltérő célokra.

A kiterjesztett sorszámok csak az adatútvonalhoz tartoznak. Kibővítik a sorszámteret, és a CHILD javaslat részeként tárgyalják meg őket, ezért az ottani eltérés egy CHILD-ajánlatot utasít el, miközben az IKE SA érintetlen marad.

Hogyan választódik ki egyetlen teljes ajánlat

Minden javaslat egy készlet, és a válaszadó olyan készletet keres, amelyben minden kötelező mező elfogadható. Két lista egyaránt tartalmazhat AES-t és SHA-256-ot, és mégsem lehet kompatibilis bejegyzésük, mert a kulcshossz, a PRF vagy a DH-csoport eltér. Az összehasonlítás javaslatonként történik, nem algoritmusonként.

Amikor semmi sem egyezik, a válaszadó NO_PROPOSAL_CHOSEN üzenetet küld a meghiúsult SA-típussal. Olvassa el, melyik javaslatlistára vonatkozik az értesítés, mielőtt szerkesztené a konfigurációt; az ESP algoritmusainak módosítása elutasított IKE-javaslat esetén egy hibakeresési ciklust pazarol el.

Érdemes ismerni a kiválasztási viselkedést, amikor profilt hangol. Egyes megvalósítások a kezdeményező sorrendjét részesítik előnyben, mások a helyi szabályzat szerint rendezik át, ezért eltűnhet egy két szállító között működő készlet amikor megfordítja, melyik fél indítja a kapcsolatot.

Az AEAD eltávolít egy mezőt, nem hozzáad egyet

Az AES-GCM és a ChaCha20-Poly1305 egy műveletben hitelesít és titkosít. Amikor bármelyiket ESP-hez választják, az integritásalgoritmus nem külön tárgyalható, mert az AEAD-szerkezet már lefedi. Ezért az AES-GCM-et SHA-256-tal párosító javaslat legjobb esetben felesleges, legrosszabb esetben elutasított.

A PRF az IKE oldalán továbbra is külön áll, mert a vezérlőcsatorna kulcsait származtatja, nem a hasznos terhelést védi. Ezért egy IKE-javaslat jogszerűen kombinálhat AEAD-rejtjelezőt PRF-fel és DH-csoporttal, miközben a megfelelő ESP-javaslat csak az AEAD-rejtjelezőt és az opcionális PFS-csoportot sorolja fel.

A kulcshossz a titkosítási token része, ezért az AES-128-GCM és az AES-256-GCM külön ajánlat. Egy olyan útmutatóból másolt profil, amely 256-bit kulcsokat feltételezett, nem fog egyezni a 128-bit-re beállított végponttal, pedig mindkét sor azt mondja, AES-GCM. Két fél megegyezhet a rejtjelezőcsaládban, és mégis elutasíthatja egymást a kötőjel utáni szám miatt.

A telepített SA-t olvassa, ne a konfigurációt

A beállított javaslatlista egy ajánlat; a telepített SA az eredmény. A strongSwanon és Linux-kernelen mindkét nézet elérhető:

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

swanctl --list-sas kinyomtatja az SA-nként megtárgyalt algoritmusokat, beleértve azt is, használ-e a CHILD AEAD-t. ip xfrm state megmutatja, mit telepített valójában a kernel, és itt erősítheti meg, hogy egy kulcsfrissítés nem esett vissza a dokumentálttól eltérő készletre.

Javítás után mentse el ezt a kimenetet a konfiguráció mellé. Amikor egy kliensfrissítés megváltoztatja az alapértékeit, a rögzített készlet viszonyítási alapot ad az összehasonlításhoz, és az összehasonlítás arra a mezőre mutat, amely elmozdult, ahelyett hogy a vizsgálatot elölről kezdené.