L2TP/IPsec ажиллахгүй байна: IPsec, туннелийн баталгаажуулалт эсвэл PPP нэвтрэлтийг ялгана уу

Нэг L2TP/IPsec холболт дотор гурван зүйл баталгааждаг бөгөөд тэдгээрийн зөвхөн нэг нь залгаж буй хүнийг хамаарна. IPsec нь туннелийн төгсгөлийн цэгүүдийг нотолж, L2TP хяналтын холболт нь өөрийн нууцаар түншүүдийг дахин нотолж болно, дараа нь PPP нь сессийн доторх хэрэглэгчийн бүртгэлийг нотолно. Аль ч үе шатны алдаа нь клиентийн харилцах цонхонд ерөнхий нэвтрэлтийн алдаа мэт харагдаж, серверийн логт огт өөрөөр харагдана. Үе шатуудыг дараалан туулж, эхний бүтэлгүйтсэн дээр зогсоо, учир нь шалгагдаагүй үе шатны доорх бүх үе шат мөн шалгагдаагүй юм.

Гурван баталгаажуулалтын үе шат, гурван өөр таних тэмдэг

IPsec нь урьдчилан хуваалцсан түлхүүр эсвэл гэрчилгээ ашиглан төгсгөлийн цэгүүд хэнд хамаарахыг нотолно. Тэр таних тэмдэг нь машин эсвэл гарцуудад хамаарах бөгөөд гарын самбар дээрх хүнд хэзээ ч хамаарахгүй. Энэ үе шатанд түншүүд тохиролцож чадахгүй бол нэг ч L2TP пакет солилцохгүй.

L2TP хяналтын холболт нь хоёр төгсгөлд заавал байх ёстой хуваалцсан нууцаар удирдуулагдах хоёр дахь, тусдаа сорилт-хариу солилцоог нэмж болно.

RFC 2661 тэр хяналтын холболтын баталгаажуулалтыг сонголтоор хийдэг нь ижил алдаа хоёр серверт яагаад өөр шинж тэмдэг үүсгэдэг вэ гэдгийг тайлбарлана. Туннелийн нууцыг хэзээ ч тохируулаагүй байршуулалт үе шатыг бүрэн алгасдаг; зөвхөн нэг талд тохируулсан байршуулалт PPP санал болгохоос өмнө бүтэлгүйтдэг. Дараа нь PPP хэрэглэгчийг PAP, CHAP эсвэл MSCHAPv2-оор баталгаажуулж, нэрийг орон нутгийн, chap-secrets эсвэл RADIUS дээр байж болох бүртгэлийн санд дамжуулна. Тэр үед буруу нууц үг таныг ажиллаж буй туннель, бүтэлгүйтсэн сессийн хамт үлдээнэ.

Тохиргоог засахын өмнө зогсох цэгийг уншина уу

Төлөвийн гаралт strongSwan-ийнх уу эсвэл Libreswan-ийнх үү гэдгийг мэдэхийн тулд ipsec --version-ээр эхэл. Дараа нь клиентийн харилцах цонхыг биш серверийн логийг унш, учир нь сервер аль үе шат татгалзсаныг бүртгэдэг.

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

Түлхүүрийн материал, нууц үгийг тэр буулгалтаас гадна байлга; үе шатны нэр ажлыг чиглүүлдэг бөгөөд алдагдсан урьдчилан хуваалцсан түлхүүр тасалбарыг илүү муу үр дагавартайгаар дахин нээдэг.

Эхний үе шат: IPsec холбоолттой юу?

strongSwan дээр ipsec statusall эсвэл Libreswan дээр ipsec whack --status ажиллуулж, тэгээс ялгаатай тоолууртай тогтсон хүүхэд холбоолтыг хай. ip xfrm state хоёуланд нь цөмийн харагдацыг харуулна. Тоолуур нь өсөж буй суулгасан SA хос нь эхний үе шат дууссан гэсэн үг бөгөөд цааш явж болно.

Холбоолт огт байхгүй нь түншийн хаяг, саналын багц эсвэл урьдчилан хуваалцсан түлхүүр рүү заадаг, заримдаа UDP 500-г дахин бичдэг ч UDP 4500-г хаядаг төхөөрөмж рүү ч заадаг. Тогтсоны дараа хэдхэн секундын дотор алга болох холбоолт нь ихэвчлэн нэвтрэх мэдээллийн асуудал биш, хоёр төгсгөлийн амьдрах хугацааны зөрүү юм. Ямар нэг зүйлийг дахин бичихээс өмнө хоёр тал ижил шифрлэлт, хэшийн саналыг жагсааж байгаа эсэхийг шалга. Хэрэв үгүй бол ямар ч түлхүүр хэзээ ч ажиллахгүй.

Холбоолт дутуу байхад зогсоо. Тэр үед PPP тохиргоог засах нь юу ч өөрчлөхгүй бөгөөд жинхэнэ гэмтлийг дараагийн хүнээс нуудаг.

Хоёр дахь үе шат: L2TP хяналтын холболт баталгаажсан уу?

IPsec ажиллаж эхэлсний дараа L2TP демоныг тогтсон төлөвт хүрэх хяналтын холболтыг ажигла, учир нь PPP түүнээс өмнө эхэлж чадахгүй. Хяналтын холболт дээрх татгалзал нь туннелийн нууц төгсгөлүүдийн хооронд өөр байна, эсвэл нэг төгсгөл нөгөө нь хэзээ ч илгээдэггүй нууцыг шаардаж байна гэсэн үг. Клиентүүд ихэвчлэн shared secret гэсэн шошготой нэг талбарыг харуулдаг бөгөөд энэ нь ихэвчлэн L2TP-д биш IPsec-д хамаарна. Түүнийг бөглөх нь туннелийн нууцыг тохируулахгүй, арилгах нь идэвхгүй болгохгүй.

Аль ч тал туннелийн нууц тохируулаагүй бол энэ үе шатыг алгасаж, хяналтын холболтын бүтэлгүйтлийг хүртээмжийн асуудал гэж үз. UDP 1701 демонд хүрч, хоёр төгсгөл ижил капсулчлалд санал нийлж байгааг батал. Тэр хоёр нөхцлийн аль нэгэнд зориулж бичсэн галт ханын дүрэм хагас нээгддэг холболтын нийтлэг шалтгаан.

PPP-ийн хэлэлцээрийг эхлүүлсэн сессийг л туннелийн үе шатыг үнэхээр давсан.

Гурав дахь үе шат: PPP бүртгэлээс татгалзаж байна уу?

PPP-ийн бүтэлгүйтэл гаднаас өөрөөр харагдана: туннель тогтсон, сессия эхэлж, демон нь баталгаажуулалтын аргын бүтэлгүйтэл эсвэл бүртгэлийн татгалзалыг бүртгэдэг. Тэр мессежид нэрлэсэн аргыг унш. PAP болон CHAP өөр шалтгаанаар бүтэлгүйтдэг бөгөөд нэгээс татгалзсан сервер зөвхөн түүнийг санал болгодог клиентээс татгалзана.

Linux сервер дээр демоноос PPP-д өгдөг тохиргооны файлыг, ихэвчлэн /etc/ppp/options.xl2tpd, шалгаж ямар аргууд хүлээн авагдаж, бүртгэлүүд хаана шийдэгддэгийг батал. RADIUS-д байдаг ч орон нутгийн нууцын файлд байдаггүй нэр цэвэрхэн бүтэлгүйтэж буруу нууц үг мэт харагдана. Дараа нь клиент серверийн хүлээн авдаг аргыг санал болгож байгаа эсэхийг, сервер хэлэлцэхээс татгалздаг илүү хүчтэй аргыг биш гэдгийг шалга. Энэ үе шатыг засахын тулд урьдчилан хуваалцсан түлхүүрийг өөрчлөх нь үдээс хойшхи цагыг үрэгдүүлж, юу ч өөрчлөхгүй.

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