Mis kuulub IPsec-i ettepanekusse? IKE ja ESP väljad

IKE käivitub, mõlemad osapooled reklaamivad AES-i ja tunnel ebaõnnestub ikkagi veaga NO_PROPOSAL_CHOSEN. Logi nimetab ettepaneku, kuid mitte välja, mis ei sobinud. Ettepanek on üks terviklik pakkumine ja üks sobimatu väli muudab kehtetuks kogu kombinatsiooni, mitte ainult selle rea. Selle lugemine kui kott sõltumatuid algoritmivalikuid on tavaline põhjus, miks sobimatus jääb nähtamatuks.

Kaks läbirääkimist eraldi ettepanekute loenditega

IKEv2 ehitab kaks turvaühendust. Esimene on IKE SA, mis kaitseb juhtimisvahetust ennast, ja teine on CHILD SA, mis kannab teie liiklust ESP kaudu. Kummallgi on oma ettepanekute loend, ja osapool võib ühe vastu võtta ning teise tagasi lükata.

See jaotus selgitab tavalist segadust: töötav IKE SA tõestab ainult seda, et juhtimiskanali algoritmid sobisid. Kui CHILD ettepanek ebaõnnestub, ei kanna tunnel ühtegi paketti, kuigi esimene faas on lõpetatud ja logid näevad ülaosas terved välja.

Ka järjekord iga loendi sees on oluline. Vastaja valib algataja järjestatud pakkumiste hulgast, seega laialt ühilduva kirje tõstmine kitsa kohale muudab, milline komplekt paigaldatakse, ilma et ükski algoritmi nimi muutuks. Kinnitage see järjekord konfiguratsioonis, selle asemel et loota vaikeväärtustele. Stabiilne järjekord teeb mõttekaks ka logide võrdlemise saidi vahel.

Millised väljad kuuluvad millisele ettepanekule

Väljade komplekt on väike, kuid see ei ole kahes läbirääkimises identne. Lugege tabelit rida-realt, sest ühe veeru väli võib teises puududa. Süntaks erineb implementatsiooniti; strongSwani ettepanekute dokumentatsioon on üks konkreetne viide.

Krüpteerimisväli nimetab šifri ja enamikus süntaksites selle võtmepikkuse. Terviklikkuse väli nimetab räsi, mida kasutatakse šifreeritud teksti autentimiseks, ja PRF nimetab funktsiooni, mis tuletab IKE SA jaoks võtmematerjali. DH-grupp loob värske ühise salajase materjali, mistõttu see esineb mõlemal pool, kuid erinevatel eesmärkidel.

Laiendatud järjekorranumbrid kuuluvad ainult andmete teele. Need laiendavad järjekorraruumi ja neid läbiräägitakse CHILD ettepaneku osana, seega sobimatus seal lükkab CHILD pakkumise tagasi, jättes IKE SA puutumata.

Kuidas valitakse üks terviklik pakkumine

Iga ettepanek on komplekt ja vastaja otsib komplekti, kus iga nõutav väli on vastuvõetav. Kaks loendit võivad mõlemad sisaldada AES-i ja SHA-256-te ning siiski mitte ühtegi ühilduvat kirjet, sest võtmepikkus, PRF või DH-grupp erinevad. Võrdlus toimub ettepaneku, mitte algoritmi kaupa.

Kui miski ei sobi, saadab vastaja NO_PROPOSAL_CHOSEN koos SA tüübiga, mis ebaõnnestus. Lugege, millisele ettepanekute loendile teade viitab, enne kui konfiguratsiooni muudate; ESP algoritmide muutmine siis, kui IKE ettepanek tagasi lükati, raiskab ühe silumistsükli.

Valikukäitumist tasub teada, kui profiili häälestate. Mõned implementatsioonid eelistavad algataja järjekorda, teised järjestavad kohaliku poliitika järgi ümber, seega kahe tarnija vahel töötav komplekt võib kaduda kui pöörate ümber, kumb pool ühenduse algatab.

AEAD eemaldab välja, mitte ei lisa seda

AES-GCM ja ChaCha20-Poly1305 autendivad ja krüpteerivad ühe toiminguga. Kui kumbki neist valitakse ESP jaoks, ei läbiräägita terviklikkuse algoritmi eraldi, sest AEAD-konstruktsioon katab selle juba. Seega on AES-GCM-i ja SHA-256-te siduv ettepanek parimal juhul üleliigne ja halvimal juhul tagasi lükatud.

PRF jääb IKE poolel eraldi, kuna see tuletab võtmeid juhtimiskanali jaoks, mitte ei kaitse kasulikku koormust. Sellepärast võib IKE ettepanek seaduslikult ühendada AEAD-šifri PRF-i ja DH-grupiga, samas kui vastav ESP ettepanek loetleb ainult AEAD-šifri ja valikulise PFS-grupi.

Võtmepikkus on krüpteerimistõendi osa, seega on AES-128-GCM ja AES-256-GCM erinevad pakkumised. Juhendist kopeeritud profiil, mis eeldas 256-bit võtmeid, ei sobi lõpp-punktiga, mis on konfigureeritud 128-bit jaoks, isegi kui mõlemad read ütlevad AES-GCM. Kaks osapoolt võivad šifriperekonnas kokku leppida ja siiski teineteist tagasi lükata sidekriipsu järel oleva numbri tõttu.

Lugege paigaldatud SA-d, mitte konfiguratsiooni

Konfigureeritud ettepanekute loend on pakkumine; paigaldatud SA on tulemus. Nii strongSwanis kui Linuxi kernelis on mõlemad vaated saadaval:

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

swanctl --list-sas prindib iga SA kohta läbiräägitud algoritmid, sealhulgas selle, kas CHILD kasutab AEAD-i. ip xfrm state näitab, mida kernel tegelikult paigaldas, ja see on koht, kus kinnitada, et võtmeuuendus ei langenud tagasi teistsugusele komplektile kui see, mille dokumenteerisite.

Salvestage see väljund paranduse järel konfiguratsiooni kõrvale. Kui kliendi uuendus muudab vaikeväärtusi, annab salvestatud komplekt teile võrdlemiseks baasjoone, ja võrdlus osutab väljale, mis liikus, selle asemel et uurimist algusest alata.