L2TP/IPsec ishlamayapti: IPsec, tunnel autentifikatsiyasi yoki PPP kirishini ajrating

Bitta L2TP/IPsec ulanishi ichida uchta narsa autentifikatsiyadan o'tadi va ulardan faqat bittasi qo'ng'iroq qilayotgan odamga tegishli. IPsec tunnelning chekka nuqtalarini isbotlaydi, L2TP boshqaruv ulanishi sheriklarni o'z siri bilan qayta isbotlashi mumkin, so'ngra PPP sessiya ichidagi foydalanuvchi hisobini isbotlaydi. Har qanday bosqichdagi xato mijoz muloqotida umumiy kirish xatosi kabi ko'rinadi va server jurnalida butunlay boshqacha ko'rinadi. Bosqichlarni tartib bilan o'ting va birinchi muvaffaqiyatsiz bo'lganida to'xtang, chunki tekshirilmagan bosqich ostidagi har bir bosqich ham tekshirilmagan.

Uchta autentifikatsiya bosqichi, uchta turlicha shaxs

IPsec chekka nuqtalar kimga tegishli ekanini oldindan bo'lishilgan kalit yoki sertifikat yordamida isbotlaydi. Bu shaxs mashinalar yoki shlyuzlarga tegishli, klaviatura oldidagi odamga hech qachon tegishli emas. Sheriklar bu bosqichda kelisha olmasa, birorta L2TP paketi almashilmaydi.

L2TP boshqaruv ulanishi ikkinchi, alohida chaqiriq-javob almashinuvini qo'shishi mumkin, uni ikki tomon ham ega bo'lishi shart bo'lgan umumiy sir boshqaradi.

RFC 2661 bu boshqaruv ulanishi autentifikatsiyasini ixtiyoriy qiladi, bu esa bir xil xato ikki serverda nima uchun turlicha belgilar berishini tushuntiradi. Tunnel sirini hech qachon so'xlamagan joylashtirish bosqichni butunlay o'tkazib yuboradi; uni faqat bir tomonda so'xlagan joylashtirish PPP taklif qilinishidan oldin muvaffaqiyatsiz bo'ladi. So'ngra PPP foydalanuvchini PAP, CHAP yoki MSCHAPv2 bilan autentifikatsiya qiladi va ismni mahalliy, chap-secrets ichida yoki RADIUSda bo'lishi mumkin bo'lgan hisoblar omboriga topshiradi. O'sha paytdagi noto'g'ri parol baribir sizni ishlaydigan tunnel va muvaffaqiyatsiz sessiya bilan qoldiradi.

Konfiguratsiyani o'zgartirishdan oldin to'xtash joyini o'qing

Holat chiqishi strongSwan yoki Libreswan ekanini bilish uchun ipsec --version bilan boshlang. So'ngra mijoz muloqotini emas, server jurnalini o'qing, chunki qaysi bosqich rad etganini server yozadi.

Odatda bitta satr chiptani hal qiladi: IKE yoki takliflar haqidagi shikoyat birinchi bosqich, boshqaruv ulanishi haqidagi xabar ikkinchi bosqich, PPP usuli yoki hisob rad etilishi uchinchi bosqich. O'sha satrni vaqt belgisi bilan chiptaga ko'chiring. Mijoz tomondan taxmin qilish sizda allaqachon bor yagona dalilni behuda sarflaydi.

Kalit materiali va parollarni o'sha joylashtirishdan tashqarida saqlang; bosqich nomi ishni yo'naltiradi, oshkor bo'lgan oldindan bo'lishilgan kalit esa chiptani yomonroq oqibatlar bilan qayta ochadi.

Birinchi bosqich: IPsecda assotsiatsiya bormi?

strongSwanda ipsec statusall yoki Libreswanda ipsec whack --status ishga tushiring va nolga teng bo'lmagan hisoblagichlar bilan o'rnatilgan bola assotsiatsiyani qidiring. ip xfrm state ikkalasida ham yadro ko'rinishini ko'rsatadi. Hisoblagichlari o'sayotgan o'rnatilgan SA juftligi birinchi bosqich tugaganini va davom etishingiz mumkinligini bildiradi.

Assotsiatsiyaning umuman yo'qligi sherik manziliga, takliflar to'plamiga yoki oldindan bo'lishilgan kalitga ishora qiladi, ba'zan esa UDP 500ni qayta yozib, UDP 4500ni tashlab yuboradigan qurilmaga ham ishora qiladi. O'rnatilib, bir necha soniyadan keyin yo'qolib qoladigan assotsiatsiya odatda ishonch ma'lumotlari muammosi emas, ikki tomon o'rtasidagi umr mos kelmasligi. Biror narsani qayta yozishdan oldin ikkala tomon ham bir xil shifrlash va xesh takliflarini sanab chiqishini tekshiring. Aks holda, hech bir kalit hech qachon ishlamaydi.

Assotsiatsiya yo'q ekan, to'xtang. O'sha paytda PPP parametrlarini o'zgartirish hech narsani o'zgartirmaydi va haqiqiy nosozlikni keyingi odamdan yashiradi.

Ikkinchi bosqich: L2TP boshqaruv ulanishi autentifikatsiyadan o'tdimi?

IPsec ko'tarilgach, L2TP demonida o'rnatilgan holatga yetadigan boshqaruv ulanishini kuzating, chunki PPP bundan oldin boshlana olmaydi. Boshqaruv ulanishidagi rad etish tunnel siri tomonlar o'rtasida farq qilishini yoki bir tomon ikkinchisi hech qachon yubormaydigan sirni talab qilishini bildiradi. Mijozlar ko'pincha shared secret yorlig'i bilan bitta maydonni ko'rsatadi va u odatda L2TPga emas, IPsecga tegishli. Uni to'ldirish tunnel sirini so'xlamaydi, uni tozalash esa o'chirmaydi.

Agar hech bir tomon tunnel sirini so'xlamagan bo'lsa, bu bosqichni o'tkazib yuboring va boshqaruv ulanishi xatosini buning o'rniga yetib borish muammosi deb qarang. UDP 1701 demonga yetib borishini va ikki tomon bir xil inkapsulyatsiyaga kelishishini tasdiqlang. Shu ikki shartdan biriga yozilgan xavfsizlik devori qoidasi yarim ochiladigan ulanishning odatiy sababidir.

Faqat PPP muzokaralarini boshlagan sessiya tunnel bosqichidan chinakam o'tgan.

Uchinchi bosqich: PPP hisobni rad etyaptimi?

PPP xatosi tashqaridan boshqacha ko'rinadi: tunnel o'rnatilgan, sessiya boshlanadi va demon autentifikatsiya usuli xatosini yoki hisobni rad etishni qayd etadi. O'sha xabarda nomlangan usulni o'qing. PAP va CHAP turli sabablarga ko'ra muvaffaqiyatsiz bo'ladi va birini rad etgan server faqat o'shani taklif qilgan mijozni ham rad etadi.

Linux serverda demon PPPga beradigan parametrlar faylini, odatda /etc/ppp/options.xl2tpd, tekshiring va qaysi usullar qabul qilinishini hamda hisoblar qayerda hal qilinishini tasdiqlang. RADIUSda bor bo'lib, mahalliy sir faylida yo'q ism toza muvaffaqiyatsiz bo'ladi va noto'g'ri parolga o'xshaydi. So'ngra mijoz server qabul qiladigan usulni taklif qilayotganini, server muzokara qilishdan bosh tortadigan kuchliroq usulni emasligini tekshiring. Bu bosqichni tuzatish uchun oldindan bo'lishilgan kalitni almashtirish tushdan keyingi vaqtni behuda sarflaydi va hech narsani o'zgartirmaydi.

Sessiya nihoyat ko'tarilganda, manzillarni taqsimlash, DNS va marshrutlar hali tekshirilmagan, va har biri o'ziga xos tarzda jimgina muvaffaqiyatsiz bo'ladi. Uch qatlamni yozuvlaringizda alohida saqlang: to'g'ri kalit va noto'g'ri hisob har doim muvaffaqiyatsiz bo'ladi, bir qatlamni tuzatish hech qachon boshqasini tuzatmaydi.