strongSwan send_cert: калі адпраўляецца сертыфікат IKE

Шлюзы запісваюць у журнал памылкі аўтэнтыфікацыі, звязаныя з сертыфікатамі, і першая думка — дадаць атрымальніку яшчэ адзін CA. Гэта мяркуе, што сертыфікат прыйшоў і быў адхілены. Іншая магчымасць — ён ніколі не адпраўляўся, і гэта вырашае палітыка злучэння адпраўніка. Перш чым змяняць давер, высветліце, які з двух выпадкаў адбыўся.

Што насамрэч кіруе send_cert

Аўтэнтыфікацыя па сертыфікаце патрабуе, каб сертыфікат канчатковага аб'екта другога боку дайшоў да яго праз абмен IKE або праз папярэднюю падрыхтоўку. У swanctl параметр злучэння send_cert вызначае, ці ўключае гэты канцавы пункт карысную нагрузку свайго сертыфіката: ніколі, заўсёды або ifasked. Тыповае значэнне ifasked адпраўляе яго ў адказ на запыт сертыфіката ад peer. Запыт сертыфіката — асобны параметр, бо прасіць другі бок пра яго сертыфікат не тое самае, што прапаноўваць свой.

Старыя разгортванні ipsec.conf выкарыстоўвалі leftsendcert і rightsendcert, і гэтыя назвы адпавядаюць лакальнай і аддаленай ролям, а не непасрэдна swanctl.

Прачытайце адну спробу, перш чым змяняць злучэнне

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Спіс злучэнняў паказвае зададзенае значэнне send_cert, а спіс SA паказвае, якія злучэнні сапраўды ўзняліся. Журнал дадае падрабязнасці ўзгаднення: ці прыйшоў запыт сертыфіката і ці пайшла карысная нагрузка сертыфіката. Агульная памылка аўтэнтыфікацыі не паказвае на праблему дастаўкі, таму знайдзіце канкрэтны абмен, перш чым рабіць высновы. Запішыце адзнаку часу спробы, каб акно журнала ахоплівала ўсё рукапоцісканне.

Давер атрымальніка — асобнае рашэнне

Дастаўка і давер — розныя ўласцівасці, і выпраўленне аднаго не выпраўляе другога. Атрымальнік павінен мець патрэбны якар даверу, атрымаць прыдатны ланцуг і супасці з чаканай ідэнтычнасцю peer. Сертыфікат канчатковага аб'екта, які прыходзіць без свайго прамежкавага сертыфіката, усё роўна не праходзіць строгую праверку ланцуга. І наадварот, усталяванне CA зусім не прымушае peer адпраўляць свой сертыфікат.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Праверка паказвае, які выдавец падпісаў сертыфікат і калі ён сканчаецца, і менавіта гэтаму мусіць адпавядаць якар атрымальніка. Давярайце выдавецкаму CA, якім валодае разгортванне, а не кожнаму прамежкаваму сертыфікату ў ланцугу, бо падвышэнне кожнага прамежкавага да каранёвага пашырае давер далёка за межы аднаго peer. Пакідайце праверку ідэнтычнасці ўключанай, бо злучэнне, якое праходзіць толькі з выключанай праверкай, — не выпраўленне. Там, дзе ланцуг няпоўны, выпраўляйце падрыхтоўку, а не палітыку адпраўніка.

Змяняйце адпраўніка толькі з доказамі

Калі журнал паказвае, што сертыфікат ніколі не адпраўляўся, а атрымальнік яго сапраўды запытваў, значэнне send_cert always — абгрунтаваная змена для гэтага злучэння. Прымяніце яго ў канфігурацыі swanctl, перазагрузіце злучэнні і ўсталюйце новы сеанс замест паўторнага выкарыстання наяўнага SA. Пацвердзіце, што карысная нагрузка сертыфіката цяпер з'яўляецца і што атрымальнік прымае яе адносна патрэбнага якара. Калі нічога не змяняецца, памылка была на баку даверу і налада адпраўніка не была прычынай.

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