Какво влиза в една IPsec заявка? Полета на IKE и ESP

IKE стартира, двете страни обявяват AES, а тунелът все пак се проваля с NO_PROPOSAL_CHOSEN. Журналът посочва заявката, но не и полето, което не е съвпаднало. Заявката е едно цялостно предложение и едно несъвместимо поле обезсилва цялата комбинация, а не само онзи ред. Четенето ѝ като набор от независими избори на алгоритми е обичайната причина несъответствието да остава невидимо.

Две преговори с отделни списъци със заявки

IKEv2 изгражда две асоциации за сигурност. Първата е IKE SA, която защитава самия обмен за управление, а втората е CHILD SA, която пренася трафика ви през ESP. Всяка има свой списък със заявки и партньорът може да приеме едната и да отхвърли другата.

Това разделение обяснява често срещано объркване: работещата IKE SA доказва само, че алгоритмите на канала за управление са съвпаднали. Ако заявката за CHILD се провали, тунелът не пренася нито един пакет, дори когато първата фаза е завършена и журналите изглеждат изрядни в началото.

Редът в рамките на всеки списък също е важен. Отговарящата страна избира от подредените предложения на инициатора, така че преместването на широко съвместим запис над тесен такъв променя кой набор ще бъде инсталиран, без да се променя нито едно име на алгоритъм. Закрепете този ред в конфигурацията, вместо да разчитате на подразбиращите се стойности. Стабилният ред прави и сравнението на журнали между сайтовете смислено.

Кои полета принадлежат на коя заявка

Наборът от полета е малък, но не е еднакъв в двете преговори. Четете таблицата ред по ред, защото поле в едната колона може да липсва в другата. Синтаксисът варира според реализацията; документацията за заявки на strongSwan е един конкретен източник.

Полето за криптиране посочва шифъра и в повечето синтаксиси дължината на ключа. Полето за цялост посочва хеша, използван за удостоверяване на шифротекста, а PRF посочва функцията, която извежда ключов материал за IKE SA. Групата DH установява нов споделен таен материал, поради което присъства от двете страни, но с различни цели.

Разширените поредни номера принадлежат само на пътя за данни. Те разширяват пространството за номерата и се договарят като част от заявката за CHILD, така че несъответствие там отхвърля предложение за CHILD, без да засяга IKE SA.

Как се избира едно цялостно предложение

Всяка заявка е набор и отговарящата страна търси набор, в който всяко задължително поле е приемливо. Два списъка могат и двата да съдържат AES и SHA-256 и пак да нямат съвместим запис, защото дължината на ключа, PRF или групата DH се различават. Сравнението се извършва за всяка заявка, а не за всеки алгоритъм.

Когато нищо не съвпада, отговарящата страна изпраща NO_PROPOSAL_CHOSEN с типа SA, който се е провалил. Прочетете към кой списък със заявки се отнася известието, преди да редактирате конфигурацията; смяната на ESP алгоритмите, когато заявката за IKE е била отхвърлена, прахосва цикъл за отстраняване на грешки.

Поведението при избор си заслужава да се знае, когато настройвате профил. Някои реализации предпочитат реда на инициатора, други пренареждат според локалната политика, така че набор, който работи между двама доставчици, може да изчезне когато обърнете коя страна стартира връзката.

AEAD премахва поле, вместо да добавя такова

AES-GCM и ChaCha20-Poly1305 удостоверяват и криптират в една операция. Когато някой от тях бъде избран за ESP, алгоритъмът за цялост не се договаря отделно, защото конструкцията AEAD вече го покрива. Затова заявка, която съчетава AES-GCM с SHA-256, е в най-добрия случай излишна, а в най-лошия — отхвърлена.

PRF остава отделен от страната на IKE, тъй като извежда ключове за канала за управление, вместо да защитава полезните товари. Ето защо една IKE заявка може законно да съчетава AEAD шифър с PRF и група DH, докато съответната ESP заявка изброява само AEAD шифъра и незадължителната група PFS.

Дължината на ключа е част от токена за криптиране, така че AES-128-GCM и AES-256-GCM са различни предложения. Профил, копиран от ръководство, което предполага 256-bit ключове, няма да съвпадне с крайна точка, настроена за 128-bit такива, дори когато и двата реда казват AES-GCM. Двама партньори могат да се съгласят за семейството шифри и пак да се отхвърлят взаимно заради числото след тирето.

Четете инсталираната SA, а не конфигурацията

Конфигурираният списък със заявки е предложение; инсталираната SA е резултатът. На strongSwan и ядро на Linux и двата изгледа са налични:

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

swanctl --list-sas отпечатва договорените алгоритми за всяка SA, включително дали CHILD използва AEAD. ip xfrm state показва какво действително е инсталирало ядрото, което е мястото да потвърдите, че подмяната на ключове не е паднала на различен набор от този, който сте документирали.

Запазете този изход до конфигурацията след поправка. Когато актуализация на клиента промени подразбиращите се стойности, записаният набор ви дава базова линия за сравнение, а сравнението сочи полето, което се е преместило, вместо да започва разследването отначало.