L2TP: үхлийн дохио 15, NO_PROPOSAL_CHOSEN ба алга болсон modp1024
NO_PROPOSAL_CHOSEN-тэй хамт үхлийн дохио 15 нь 2-р үеийн зөрүү: эсвэл демон modp1024-ийг цаашид санал болгохгүй, эсвэл 1-р үеийн утга 2-р үеийн талбарт байна.
Холболт чинь гацаж, клиент гарч, дэлгэц дээрх сүүлийн мөр death_handler: Fatal signal 15 received байна. Тэр мөр тасалдлыг мэдээлдэг, шалтгааныг биш. IPsec логт нэг мөр дээр бараг үргэлж NO_PROPOSAL_CHOSEN байдаг бөгөөд энэ хос солилцооны 2-р үе рүү заадаг, тэнд хоёр тал шифрлэлт болон хэшийн сонголтыг харьцуулж, нийтлэг зүйл байхгүй бол зогсдог. Тэр үед нэвтрэх мэдээлэл хараахан илгээгдээгүй байдаг тул нууц үгийг дахин оруулах нь үр дүнг өөрчлөхгүй.
Linux клиент дээр энэ огтлолцлыг ихэвчлэн хоёр зүйл хоосолдог. Локал демон профайлын шаардсан Diffie-Hellman бүлгийг цаашид хэрэгжүүлэхгүй байж болно, эсвэл профайл 1-р үеийн саналыг 2-р үеийн талбарт агуулж болно. Хоёулаа логт ул мөр үлдээдэг бөгөөд аль нь ч бүртгэлийн асуудал биш.
Энэ хоёр мессеж үнэндээ юу гэж хэлж байна
IKE үе шаттайгаар хэлэлцдэг. 1-р үе хамгаалагдсан суваг барьж, өөрийн алгоритмуудыг сонгодог; 2-р үе буюу хүү SA нь траффикийг тусдаа багцаар зөөдөг. NO_PROPOSAL_CHOSEN нь санал болгосон хослолуудын аль нь ч хүлээн авах боломжгүй үед хариулагч буцаадаг мэдэгдэл бөгөөд INFORMATIONAL солилцооны дотор [ HASH N(NO_PROP) ] хэлбэрээр гарч ирдэг.
15-р дохио нь өөр үйл явдал: ямар нэг зүйл локал процессд зогсохыг тушааж, боловсруулагч үүнийг бүртгэсэн. Хоёр мөр хамт гарч ирвэл дараалал нь шалтгаант: эхлээд татгалзал, дараа нь унтраалт.
Нэвтрэх мэдээлэлд хүрэхийн өмнө хэлэлцээрийг уншина уу
Демон бичиж буй газарт логын түвшинг өсгөж, дараа нь гаралтыг ажиглахын зэрэгцээ дахин холбогдоорой. NetworkManager хост дээр L2TP нэмэлт нь энэ түвшинг backend-д дамжуулж, мессежүүд хуваарилалтаас хамаарч journal эсвэл сонгодог syslog файлд ордог. Эдгээрийн аль нэг нь солилцоог харуулна: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' эсвэл tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.
pluto гэж нэрлэсэн мөр libreswan-аас, charon strongSwan-аас ирдэг бөгөөд хоёулаа ижил байдлыг өөр үгээр дүрсэлдэг. Хайх нь зүйтэй хэлбэр нь дутуу бүлгийг нэрлэсэн хэлбэр, жишээ нь algorithm 'modp1024' is not supported, учир нь энэ нь бүрхэг алдааг тодорхой болгодог.
modp1024 хаашаа явсан
Diffie-Hellman 2-р бүлэг хэт сул учраас хэд хэдэн хуваарилалт 3.30-аас эхлэн libreswan руу компайл хийхээ больсон. Тэгэхэд жилийн өмнө бичсэн эсвэл зөвхөн aes128-sha1-modp1024 жагсаасан гарцын гарын авлагаас авсан профайл локал демоноос огт хийж чадахгүй зүйлийг шаарддаг. Шинэ NetworkManager-l2tp бүтээцүүд энэ үр дүнг илүү магадлалтай болгодог: 1.2.16-аас тэд багцыг Windows 10 болон iOS хэв маягийн саналуудаар сольж, libreswan илэрсэн даруйд modp1024-ийг орхидог. Эсрэг тал ихэвчлэн гэм зэмгүй бөгөөд одоо ч таны тохируулсан бүлгийг яг санал болгодог.
Энэ тэгш бус байдал нь доголдлыг санамсаргүй мэт санагдуулдаг. Хуучин клиент холбогддог, шинэчилсэн зөөврийн компьютер дээр ижил профайл холбогддоггүй, харин серверийн тохиргоо хэзээ ч хөдлөөгүй. Хохиролыг хувилбарын зөрүү учруулдаг.
Өөр нөлөөтэй хоёр засвар
Хямд засвар нь алгоритмуудыг гараар хатууруулахаа болих явдал юм. Засварлагч доторх хоёр саналын талбарыг хоослоод, алслагдсан тал хүлээн авдаг багцыг нэмэлт сонгохыг зөвшөөрөөрэй; гарц орчин үеийн бүлгүүдийг дэмждэг бол хэлэлцээр нэмэлт ажилгүйгээр дуусна.
Хоёр дахь засвар нь strongSwan суулгаснаар хуучин гарцыг хүртээмжтэй байлгадаг, түүний багцууд ихэнх хуваарилалтад 2-р бүлгийг одоо ч хэрэгжүүлдэг. Энэ нь демон солих явдал тул үнэтэй: арилгахын өмнө хост дээрх бусад туннель libreswan тохиргооноос хамаардаг эсэхийг шалгаж, Fedora дээр NetworkManager болон strongSwan нэмэлтийн хооронд SELinux татгалзал гарна гэж хүлээнэ үү. Тэдгээр татгалзал IKE мөрөнд биш, аудитын логт гарч ирдэг тул амжилттай суулгасны дараа шууд туннель эвдэрсэн мэт харагдаж болно. Ажилладаг дараалал нь эхлээд dnf install strongswan, дараа нь rpm -e libreswan.
Тохирох саналын мөрүүд ба тэдгээрийн эргэн тойрны урхи
Талбарыг гараар бөглөх шаардлагатай үед 1-р үе ба 2-р үе өөр утга авдаг. Meraki хэв маягийн эсрэг талтай ажилладаг гэж мэдэгддэг хос 1-р үед aes128-sha1-modp1024, түүний ард 3des-sha1-modp1024 санал болгодог бөгөөд хоёулаа багцыг хатуу болгодог анхааруулах тэмдгээр хаагдаж, зөвхөн тэдгээр санал илгээгддэг.
Дараа нь 2-р үе ижил хатуу тэмдэгтэйгээр, Diffie-Hellman дагаваргүйгээр aes128-sha1 болон 3des-sha1 хүртэл нарийсдаг. -modp1024 агуулсан 2-р үеийн мөр нь буруу талбар дахь 1-р үеийн утга бөгөөд хариулагч үүнийг оролдлого бүрт татгалздаг. Тэр мөрийг хоёр дахь профайл руу хуулбал хоёр дахь профайл мөн адил бүтэлгүйтэж, ингэснээр нэг бичгийн алдаа бүх флотын осол болдог.
Бусад гэмтэл нь саналын зөрүү биш мөртлөө ижил цонхыг өмсдөг. KDE дээр нэмэлт суулгасан байхад L2TP төрөл жагсаагдаж болох боловч холболт бүр даруй үхдэг, учир нь холболтын засварлагч болон ажиллах үеийн туслахууд тусдаа багц хэлбэрээр ирдэг. Дэлгэцгүй хост ажиллаж буй ширээний профайлыг дахин ашиглаж болно: /etc/NetworkManager/system-connections/-аас хуулж, горимыг 600 болгож, дараа нь nmcli con reload ажиллуулна. Үүнийг nmcli con up id work-l2tp-оор өргөж, учир нь нүцгэн хэлбэр UUID шаарддаг, мөн хуучирсан ifname бичлэгийг устга, эс бөгөөс бусад нь зөв байхад менежер Could not find source connection гэж хариулна.
Урьдчилан хуваалцсан түлхүүрийг тодорхой текстээр эсвэл 0s ба дараа нь base64 хэлбэрээр хадгалж болно; хоёр хэлбэр ажилладаг боловч утга нь гарцтай байт байтаар таарах ёстой, үүнд түүнтэй хамт хуулсан төгсгөлийн зайнууд орно.