Што ўваходзіць у прапанову 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 паказвае, што ядро фактычна ўсталявала, і гэта месца, дзе пацвердзіць, што перазамена ключоў не адышла да іншага набору, чым той, які вы дакументавалі.

Захавайце гэты вывад побач з канфігурацыяй пасля выпраўлення. Калі абнаўленне кліента змяняе прадвызначэнні, запісаны набор дае вам базавую лінію для параўнання, і параўнанне паказвае на поле, якое зрушылася, замест таго каб пачынаць расследаванне з пачатку.