Шта улази у 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 показује шта је кернел стварно инсталирао, и то је место где потврђујете да обнова кључева није пала на другачији скуп од оног који сте документовали.

Сачувајте тај излаз уз конфигурацију након поправке. Када ажурирање клијента промени подразумеване вредности, забележени скуп вам даје основу за поређење, а поређење показује на поље које се померило уместо да истрагу почиње изнова.