Linuxda IPsecsiz L2TP: xl2tpd, pppd va NAT

Yalang'och L2TP — konvert ichidagi PPP, boshqa hech narsa emas. U sizning kadrlaringizni tashiydi; ularni shifrlamaydi va narigi uchda kim o'tirganini isbotlamaydi, shu sababli deyarli har bir joylashtirish uning ostiga IPsec qo'yadi. Yalang'och versiyani ishga tushirishning halol sabablari hali ham bor: laboratoriya stendi, migratsiya bosqichi yoki allaqachon boshqa himoyalangan yo'l ichida turgan aloqa.

Agar baribir davom etsangiz, bu ogohlantirishni dizayn yozuviga yozing va o'sha yerda qoldiring. Keyingisi — Debian va RHEL oilasidagi xostlarda men ishlatadigan operatsion yo'l: qaysi fayl nimaga javobgar, klassik qotib qolishning oldini oladigan MTU va tunnelni arziydigan qiladigan yo'naltirish qoidalari.

Uch fayl ishni bo'lishadi

xl2tpd boshqaruv ulanishini tugatadi va har bir sessiyani PPP demoniga topshiradi, shuning uchun konfiguratsiya bir-birining fayllarini hech qachon o'qimaydigan ikki dastur o'rtasida bo'lingan. Tinglovchi /etc/xl2tpd/xl2tpd.conf ichida, [lns default] bo'limining ichida yashaydi; u manzillar hovuzini ip range bilan, server tomonini local ip bilan va PPP ga topshirishni pppoptfile bilan nomlaydi. require authentication = yes ni yoqing, length bit va flow bit yoniq qolsin, xostda boshqa hech narsa ishlatmaydigan hovuzni tanlang.

PPP siyosati shu parametr nomlaydigan faylga tegishli, odatda /etc/ppp/options.xl2tpd: auth, pap, chap va mschap uchun rad javoblari, require-mschap-v2, 1460 MTU va MRU, hamda aloqa ko'tarilgandan keyin mijoz yeta oladigan DNS manzili. Hisob ma'lumotlari yana uchinchi fayl, /etc/ppp/chap-secrets, u yerda ikkinchi maydon LNS bo'limi nomiga mos kelishi kerak, to'rtinchi maydon esa hovuzdan aniq manzilni mahkamlashi mumkin.

Tunnel nega ulanadi va keyin qotib qoladi

1500 baytli Ethernet kadri o'z sarlavhalariga allaqachon bayt sarflaydigan yo'lga sig'maydi. Tashqi IPv4 sarlavhasi 20, UDP 8, L2TP sarlavhasi esa taxminan 12 ni oladi, bu PPP va uning yuklamasiga 1460 qoldiradi. Aynan shu kichik raqamni PPP da e'lon qilish katta paketlarning bo'linishini yoki o'rtada bir joyda jimgina yo'qolishini oldini oladi.

Belgi — haqiqiy trafik kelguncha sog'lom ko'rinadigan tunnel: pinglar va boshqaruv xabarlari o'tadi, fayl nusxalash qotib qoladi, jurnalda hech narsa buni tushuntirmaydi. Ikki uchda MTU va MRU ni birga pasaytiring. Faqat mijozni sozlash odatda qattiq qotib qolishni vaqti-vaqti bilan bo'ladigan holatga aylantiradi, buni aniqlash qiyinroq.

Bitta port ikki suhbatni tashiydi

UDP 1701 protokolning ikki yarmi ostida yotadi va shu bir fakt sozlashning boshqa har qanday qismidan ko'ra ko'proq tarmoq ekrani qoidalarini buzadi. Avval boshqaruv ulanishini boshlash so'rovi va uning javobi keladi; keyingi sessiya so'rovi va tasdiqlash identifikator juftidan ortiq narsa o'rnatmaydi. So'ngra PPP boshqaruvni oladi: aloqa boshqaruvi, keyin autentifikatsiya, keyin manzillarni kelishish uchun IP boshqaruv protokoli. Har bir bosqichning jurnalda o'z lug'ati bor va ularning hech biri o'zini L2TP nosozligi deb e'lon qilmaydi.

Yozuvni aynan shu tartibda o'qish qaysi bosqich muvaffaqiyatsiz bo'lganini aytadi, PPP autentifikatsiyasi nosozligi esa xl2tpd ni tahrirlash bilan tuzalmaydi. Umumiy port yana bir keng tarqalgan nosozlikni tushuntiradi: oqimning faqat birinchi paketlariga ruxsat beradigan qoida sessiya o'rnashishiga yo'l qo'yadi va keyin uzatishni bloklaydi. 1701 ni butun suhbat uchun, ikki yo'nalishda ham ruxsat bering.

Tunnelni foydali qilish: yo'naltirish va NAT

Sessiya o'zi faqat serverga yetadi. Mijozlarning internetga chiqishi uchun yo'naltirish, yuqori kanalda hovuz uchun NAT qoidasi va aloqa ko'tarilgandan keyin mijoz haqiqatan so'ray oladigan DNS kerak. Hovuz LAN oralig'idan tashqarida turishi ham kerak, aks holda mijozlarga yuborilgan javoblar tunnelga qaytarilish o'rniga mahalliy tarqatiladi.

Serverda yo'naltirishni sysctl -w net.ipv4.ip_forward=1 bilan yoqing, hovuzni iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE bilan tarjima qiling, so'ngra -i ppp0 -o eth0 uchun FORWARD qoidasi bilan chiquvchi tunnel trafigini va oyna qoidasi bilan birga -m state --state RELATED,ESTABLISHED orqali qaytuvchi trafikni qabul qiling. Bu qoidalarni qayta yuklashlar orasida saqlanadigan qiling, chunki ularsiz qaytgan server aynan buzilgan L2TP konfiguratsiyasiga o'xshaydi.

Serverning o'z LAN iga yetish boshqa vazifa: LAN routerida hovuz uchun qaytish marshrutini qo'shing yoki serverda proxy ARP ishlating. LAN ichidagi biror narsa mijozlarga to'g'ridan-to'g'ri murojaat qilishi kerak bo'lganda ularni NAT orqasiga yashirish faqat keyinroq ikkinchi tuzatish seansini rejalashtiradi.

Yalang'och stek nima qilmaydi va buni qanday tekshirish kerak

Bu stekning hech bir qismi PPP kadrlarini shifrlamaydi va unda hech narsa uzoq tomonni siz haqiqatan tanlagan server sifatida autentifikatsiya qilmaydi. MS-CHAPv2 hisob ma'lumotlari almashinuvini faqat kuzatuvchi tinglovchidan himoya qiladi, ammo yo'lda turgan tajovuzkor baribir sessiyaga aralashishi mumkin. Windows ning mahalliy mijozi L2TP ni faqat IPsec bilan birga taklif qiladi, shuning uchun Linux, router proshivkasi va uchinchi tomon mijozlarini hamkor deb hisoblang. Yalang'och konfiguratsiyaga diagnostika zinapoyasi sifatida qarang, hech qachon to'xtash joyi sifatida emas.

Belgilangan tartibda tekshiring: xl2tpd -D ni oldingi planda ishga tushiring, PPP bosqichi uchun jurnalni kuzating, ikki uchda ip addr dan berilgan manzilni o'qing, so'ngra sessiya ko'tarilgandan keyin ma'lumotlar oqayotganini tasdiqlash uchun UDP 1701 ni tuting. Agar to'rttasi ham mos kelsa-yu trafik baribir o'tmasa, ayb marshrutlashda, NAT yoki MTU da, L2TP ning o'zida emas.