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

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