L2TP NO_PROPOSAL_CHOSEN: үнэндээ аль үе шат бүтэлгүйтсэн бэ?
Мэдэгдэл саналыг татгалзсаныг хэлдэг боловч алийг нь гэдгийг хэлдэггүй. Үе шатыг тодорхойлохын тулд backend-ийн бүртгэлийг уншаад, дараа нь багцуудыг гарцыг удирдаж буй хүнтэй харьцуулна уу.
NO_PROPOSAL_CHOSEN нь PPP хэрэглэгчийн нэрийг шалгахаас өмнө ирдэг бөгөөд энэ нь ашигтай баримт бөгөөд мэдэгдэл яагаад төөрөгдүүлдэг шалтгаан болдог. Нэг тал саналыг татгалзсаныг мэдээлдэг; аль параметр тохироогүйг мэдээлдэггүй бөгөөд татгалзал IKE нэгдлийг байгуулах үед гарсан уу, эсвэл дараа нь траффикийн хамгаалалтын талаар хэлэлцэх үед гарсан уу гэдгийг огт хэлдэггүй. Эдгээр хоёр боломжийн ард хоёр өөр засвар байдаг бөгөөд тэдгээрийн зөвхөн нэг нь хүмүүсийн хамгийн түрүүнд ханддаг PFS чагтлахад хамаатай.
Нэг мэдэгдэл, хоёр саналын багц
IKEv1 L2TP/IPsec зохион байгуулалтад хоёр хэлэлцээр дараалан явагдана. 1-р шат нь шифрлэлтийн алгоритм, бүрэн бүтэн байдлын алгоритм, Diffie-Hellman бүлгээс IKE аюулгүй байдлын нэгдлийг байгуулдаг. Дараа нь 2-р шат траффикийг хэрхэн хамгаалахыг хэлэлцдэг бөгөөд PFS шаардлага тэр хоёр дахь ярианы хэсэг юм.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Үе шатууд дараалсан тул бүтэлгүйтсэн байрлал аль жагсаалтыг харьцуулахыг хэлнэ. Мэдэгдлийн бүх оношилгооны үнэ цэнэ үүнд оршдог бөгөөд ямар ч тохиргоонд хүрэхээс өмнө үүнийг гаргаж авах нь зүйтэй.
Яагаад PFS чагт 1-р шатыг засч чадахгүй вэ
PFS-ийг унтраах нь 2-р шатын шинж чанарыг өөрчилдөг. Хэрэв талууд 1-р шатанд хэзээ ч тохиролцоогүй бол ESP яриа огт болохгүй тул чагт татгалзалд ямар ч нөлөөгүй бөгөөд иймээс түүнийг сольсноор ижил алдаа өөр цагийн тэмдэгтэй гардаг.
Эсрэг алдаа мөн адил түгээмэл. Амжилттай IKE нэгдэл нь ESP санал хүлээн зөвшөөрөгдөхүйц гэдгийг нотлохгүй бөгөөд 2-р шатын бүлэг тохирч байгааг огт нотлохгүй. Тогтоосон удирдлагын туннелийг зөвхөн 1-р шатын талаарх нотолгоо гэж үзээрэй. Хүмүүс ногоон мөрийг «туннель ажиллаж байна» гэж уншиж, дараа нь хоёр дахь хэлэлцээр эхлээгүй гэдгийг хэн ч хэлээгүй тул буруу шатанд нэг цаг зарцуулдаг.
Алгоритмуудыг сонгохоос өмнө бүртгэлийг уншаарай
Татгалзалын өмнөх мэдэгдлүүдийг холболтыг үнэхээр үйлчилж буй backend-ээс цуглуулж, тэдгээрийг ижил оролдлоготой холбоорой. Тэр холбоогүйгээр та өөр холболтын түүхийг уншиж, түүнээс дүгнэлт гаргаж байна.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanТэдгээр мөрөөс хоёр асуултад хариулна уу: 1-р шатын нэгдэл тогтсон уу, аль солилцоо бүтэлгүйтсэн бэ. Эдгээр хоёр хариулт хайлтыг нэг шинж чанарын жагсаалт болгон нарийсгана. Эргэн тойрны контекстгүй нүцгэн мэдэгдэл үүнийг хийж чадахгүй, форумын сэдвээс санал туршиж үзэх нь хичнээн уруу татагдах ч. Ажилладаг мөрийг өөр backend-тэй машинаас хуулах нь ихэвчлэн нэг татгалзлыг өөр нэгээр, бага зэрэг хожуу орлуулдаг.
Backend-ийн синтакс аялахгүй
Ямар нэг зүйлийг харьцуулахаас өмнө NetworkManager-l2tp-ийн хувилбар болон IPsec backend-ийн хувилбарыг тэмдэглээрэй. Libreswan болон strongSwan нь саналын синтакс ч, ижил алгоритмын багц ч хуваалцдаггүй тул нэгэнд ажилладаг мөр нөгөөд синтаксийн алдаа болно. Суулгасан backend нь бодлогоор IKEv1-ийг ч татгалзаж болох бөгөөд тэгвэл ямар ч санал хэзээ ч хүлээн авагдахгүй.
Төслийн README нь backend-үүдийн эдгээр ялгааг баримтлаж, 1-р шат болон 2-р шатын талбарыг тусдаа хадгалдаг. Үүнийг бүтцийн баримт бичиг гэж уншаарай, түүхэн бүх шифр, сул бүлгийг асаах урилга гэж биш, учир нь зөвхөн ингэснээр л амжилт олдог холболт бол танаас барихыг хүссэн холболт биш юм.
Багц дээр санал нэгдэж, дараа нь үе шатуудыг баталгаажуулаарай
Гарцын оператороос аль IKE болон ESP багц дэмжигдэж, зөвшөөрөгдсөнийг асуугаад, тэр хариултыг клиентийн тохиргооны файлтай биш, харин бодит саналуудтай харьцуулаарай. Хэрэв зөрүү нь 2-р шатын PFS-д тусгайлан хамаатай бол дэмжигдсэн бүлэг эсвэл тодорхой зөвшөөрөгдсөн PFS-гүй бодлогод санал нэгдээрэй. Бодлогыг алдааны нэрнээс бүү таамаглаарай.
Цорын ганц давхцал нь байгууллага цаашид хүлээн зөвшөөрөхгүй криптографыг шаарддаг бол шийдвэр нь гарц эсвэл протоколын шилжилтэд хамаарна. Клиентийн мөрийг ямар нэгэн зүйл хэлэлцэх хүртэл өргөтгөх нь мэдэгдэж буй сул талыг хажууд нь ногоон тэмдэгтэйгээр хүргэх арга юм.
Жинхэнэ зөрүүг зассаны дараа L2TP болон PPP-г судлахаас өмнө IPsec тогтсоныг баталгаажуулж, дараагийн аливаа баталгаажуулалтын татгалзлыг дараагийн шатанд хамаарах гэж үзээрэй. Дараа нь зөвшөөрөгдсөн туршилтын процесст шинэчлэлтийг туршаарай, учир нь эхний нэгдлийн тогтсон байдал түүний үлдсэн насны талаар юу ч хэлдэггүй.