IKEv2 NO_PROPOSAL_CHOSEN: аль үе шат багцыг няцаав?

Лог дахь NO_PROPOSAL_CHOSEN хүмүүсийг өмнө нь хуваалцсан түлхүүр рүү явуулдаг бөгөөд алдаа өөрчлөлтийн дараа ч хэвээр үлддэг. Энэ нь хэзээ ч итгэмжлэлийн асуудал байгаагүй: түнш тухайн солилцоонд санал болгосон бүх саналыг няцаасан бөгөөд энэ нь таних тэмдгийн бус алгоритмын тухай мэдэгдэл юм. Эхний ашигтай асуулт нь аль алгоритмыг засах биш, аль солилцоог няцаасан бэ гэдэг юм. Ямар нэгэн зүйлийг харьцуулахаас өмнө үүнд хариулна уу. Дараа нь санал болгосон бүрэн багцыг түншийн зөвшөөрсөн бүрэн багцтай харьцуулна уу.

Эхлээд: аль солилцоог няцаасан бэ

IKEv2 нь хоёр төрлийн холбоог хэлэлцдэг. IKE SA нь хэлэлцээрийг өөрөө хамгаалж, CHILD SA нь урсгалыг хамгаална. Тус бүр өөрийн саналын багцтай бөгөөд тус бүр ижил мэдэгдлээр бүтэлгүй болж болно. Эхний IKE хэлэлцээрийн үеийн няцаалт болон CHILD хэлэлцээрийн үеийн няцаалт нь өөр засвар шаарддаг бөгөөд лог нь ихэвчлэн мэдэгдлээс нэг хоёр мөр дээр солилцоог нэрлэдэг. Тэр хоёр мөрийг хамт уншина уу, эс бөгөөс буруу саналын жагсаалтыг засах болно.

Зөвхөн мэдэгдэл нь солилцоог тодорхойлохгүй. Түүний дээрх мөр нь хэлэлцэж буй SA-г нэрлэх бөгөөд тэр нэр нь шалгах саналын жагсаалтыг заана.

Бүрэн багцыг харьцуулна уу, тусдаа түлхүүр үгсийг биш

Саналын багц бол хослол: шифрлэлтийн алгоритм, бүрэн бүтэн байдал эсвэл AEAD, түлхүүр солилцох бүлэг болон аливаа псевдо санамсаргүй функц. Зөвхөн шифрлэлтийн нэрийг харьцуулах нь нийтлэг алдаа, учир нь хоёр түнш AES-256 дээр санал нэгдэж, SHA-1 болон SHA-256-ийн асуудалд санал зөрөлдөж болно. Бүтэлгүй үе шатанд санал болгосон болон зөвшөөрөгдсөн багцуудыг хажуу хажууд бичээд, дараа нь хоосон огтлолцлыг хайна уу.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Мөн хоёр хэрэгжилт таны тохируулсан зүйлийг дэмжиж байгаа эсэхийг шалгана уу. Өөр платформоос хуулсан нэр синтаксийн хувьд танил харагдаж болно харин залгаас эсвэл хэрэгжилт бүрэн байхгүй байна.

IKE багц ба ESP багц нь өөр объектууд

IKE саналыг засах нь няцаагдсан CHILD саналыг засахгүй, мөн эсрэгээрээ үнэн. strongSwan-д эдгээр нь тусдаа тохиргоо, ойролцоогоор IKE SA-д proposals = aes256-sha256-modp2048, CHILD SA-д тусдаа ESP жагсаалт. Бүтэлгүй солилцоотой тохирох жагсаалтыг өөрчилж, дараа нь засвар ажилласан гэж таамаглахгүйгээр логийг дахин уншина уу.

CHILD SA-ийн хувьд холбогдох тохиргоо нь ESP саналын жагсаалт бөгөөд IKE жагсаалт биш. IKE мөрийг түүн рүү хуулах нь задлан шинжилдэг боловч буруу объектыг хэлэлцдэг тохиргоог үүсгэдэг.

Ажиллаж байсан туннель түлхүүр шинэчлэлтэд бүтэлгүй болдог

Хэрэв туннель нэг цаг ажиллаад дараа нь бүтэлгүй болсон бол эхний хэлэлцээр нь асуудал биш. Түлхүүр шинэчлэлт нь өөр нөхцөлийг туршиж болно: эхний солилцооны дараа өөр түлхүүр солилцох бүлэг, түншүүдийн хооронд амьдрах хугацааны зөрүү эсвэл өөрчлөгдсөн хариулагчийн бодлого. Хоёр талаас шинэчлэлтийн цагийн тэмдэг болон холбооны танигчийг хадгална уу. Ийм хэв маяг нь шинэчлэлтийн үед саналын харьцуулалт шаарддаг, илүү урт таймаут биш. Таймаутын өөрчлөлт нь шинж тэмдгийг нууж, зөрүүг байранд нь үлдээдэг.

ipsec statusall холбоо бүр болон бодитоор хэлэлцсэн алгоритмуудыг харуулна. Тэр гаралт нь аль жагсаалт ашиглагдсаныг батлах хамгийн хурдан арга бөгөөд тохиргооны алдааг хэзээ ч дахин хэлэлцээгүй хуучин туннелээс ялгадаг.

ipsec statusall | grep -E "IKE:|ESP:"

Огтлолцлыг сонгоод, дараа нь хоёр үе шатыг батална уу

Администраторт хоёр түншийн дэмждэг баримтжуулсан орчин үеийн огтлолцлыг сонгуулж, бичиж авна уу. Алдааг бүх хуучин алгоритмыг идэвхжүүлэх эсвэл таних тэмдгийн баталгаажуулалтыг унтраах замаар шийдэхгүй, учир нь аль нь ч няцаалтаас гарахгүй. Өөрчлөлтийн дараа шинэ холболт үүсгээд, дараа нь түлхүүр шинэчлэлтийг албадана уу. Зөвхөн эхний холболт нь шинэчлэлтийн зам ажиллаж байгааг нотлохгүй.

Хүлээн авсан хослолыг програм хангамжийн хувилбаруудтай хамт хадгална уу. Дараагийн алдаа урсгалын сонгогчдод хамааралтай бол тусад нь авч үзнэ үү, учир нь криптографын талаарх тохиролцоо нь туннель ямар дэд сүлжээг хамгаалдгийг юу ч хэлэхгүй. strongSwan-ны саналын баримт бичиг хоёр жагсаалтын синтаксийг хамарна.