Nega PPTP va L2TP/IPsec foydalanuvchi nomi so'ralishidan oldin to'xtaydi?
Foydalanuvchi nomi so'rovi chiqmasligi PPP hech qachon boshlanmaganini bildiradi, shuning uchun xatolik transportda, kalit almashinuvida yoki tunnel sozlashda. Qayta o'rnatishdan oldin bosqichlar tartibini tekshiring.
Foydalanuvchi nomi so'rovi chiqmasligi diagnostik sovg'a: PPP hali boshlanmagan, shuning uchun hisob, parol va domen siyosati hali so'ralmagan. PPTP yoki L2TP/IPsec ulanishida klient hisob ma'lumotlarini faqat tunnel mavjud bo'lib, server PPP sessiyasini boshlagandan keyin so'raydi. O'sha lahzaga qadar muvaffaqiyatsiz bo'lishi mumkin bo'lgan hamma narsa transport, kalit almashinuvi yoki tunnel sozlashdir, bu esa «VPN buzilgan» deganidan ancha kichik hudud.
Yo'q so'rov xatolikni uch bosqichga toraytiradi
Ko'zga ko'rinadigan tarzda muvaffaqiyatli bo'lgan oxirgi bosqichni yozib qo'ying, chunki har birining egasi va yechimi boshqa. Ikki bosqich oldin tiqilib qolgan holda hisob sozlamalarini taxmin qilish — bitta tushdan keyin vaqtning yo'qolish yo'li.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
So'rovsiz muddati tugagan klient hech qachon IPsec birlashmasi olmagan, shuning uchun xatolik IKEda yoki paketlaringiz shlyuzga yetib borishida. Hisob ma'lumotlarini tekshiryapman deb xabar berib, keyin yiqilgan klient xabarning ishorasidan uzoqroqqa ketgan. So'rovdan keyin rad javobi kelsa, bu PPP autentifikatsiyasi va uning o'rni bu emas, hisob haqidagi maqola.
Birinchi bosqich: tarmoq ekrani jimgina tashlab yuboradigan protokol
PPTP boshqaruv kanali uchun TCP 1723 va ma'lumot yo'li uchun IP protokoli 47 talab qiladi, ikkalasi alohida yuradi. Ko'p tarmoqlar 1723ni o'tkazib, 47 protokolini tashlaydi, natijada muzokara qilib, keyin hech narsa tashimaydigan tunnel hosil bo'ladi. NAT qiladigan marshrutizatorga GRE qo'llab-quvvatlaydigan o'tish ham kerak, faqat IPv6 bo'lgan kirish yo'li hech qanday konfiguratsiyada PPTPni tashiy olmaydi.
IPsec ustidagi L2TP IKE uchun 500 portini va NATdan o'tish uchun 4500 portini sarflaydi, keyin L2TP trafigining o'zini 1701 ichiga o'raydi, birlashma paydo bo'lgach ESP himoyalangan yukni tashiydi. Ikki boshqaruv portiga ruxsat berib, ESPga bermasangiz, xuddi sarlavhadagi alomatni olasiz: ko'rinadigan siljish, keyin har qanday hisob ma'lumoti muloqotidan oldin o'lik klient. Telefon hotspotidan sinash klient muammosini yo'l muammosidan ajratishning arzon yo'li.
Ikkinchi bosqich: kalit bo'lmagan kalit, taklif qilinmagan taklif
Mos kelmaydigan oldindan bo'lishilgan kalit tez va jimgina muvaffaqiyatsiz bo'ladi, odatiy ko'rinishi esa ekranda to'g'ri ko'rinadigan, lekin qistirilgan satr uzilishi yoki oxirida bo'sh joy bo'lgan kalitdir. Linux klientida muloqot oynasi har doim ham haqiqat manbai emas: NetworkManagerning L2TP plagini sirlarni /etc/ipsec.d/ ostidagi fayllarda saqlaydi va /etc/ipsec.secrets hali ham qo'shadigan eski ulanish fayli siz hozir yozgan fayl o'rniga ishlatiladi. O'sha faylni xavfsiz joyga nusxalang, qo'shish yo'lidan olib tashlang va keyin kalitni qo'lda qayta yozing.
Bu bosqichning ikkinchi yarmi taklifdir. Ikkala tomon ham bir xil 1-bosqich algoritmlar to'plamida — shifrlash, yaxlitlik va Diffie-Hellman guruhi — va 2-bosqich uchun mos ESP o'zgartirishlarida kelishishi kerak, aks holda birlashma umuman shakllanmaydi. Faqat 3DES, SHA1 va MODP1024 taklif qiladigan shlyuz kuchliroq algoritmlarga sozlangan klientni rad etadi va uning jurnali rad etilgan o'zgartirishni nomlaydi. Jurnalni xizmatni yana qayta ishga tushirish o'rniga o'qisangiz, nomuvofiqlikni aytadi. Forum mavzusidan algoritm satrini nusxalash o'rniga shlyuzdan u haqiqatda qaysi o'zgartirishlar bo'yicha muzokara qilishini so'rang: uning manziliga yo'naltirilgan ike-scan muzokara qiladigan o'zgartirishlarni qaytaradi. Agar yagona taklif sizning siyosatingiz endi ruxsat bermaydigan kriptografiya bo'lsa, tuzatish klientni tushirishda emas, shlyuzda.
Windowsda kalit va autentifikatsiya usuli VPN profilida yashaydi, nomuvofiqlik esa hisob ma'lumotlari so'rovidan keyin emas, oldin ko'rinadi. Qabul qiluvchi Windows Server bo'lsa, masofadan kirish roli o'rnatilganini, sertifikat klientlar ulanadigan nomga mos kelishini va hech bir port filtri yuqoridagi protokollardan tor emasligini tasdiqlang.
Uchinchi bosqich: tunnel bor, PPP boshlanmaydi
IKE tugagach ham so'rov chiqmasa, tarmoq ekraniga emas, tunnel demoniga qarang. L2TPga UDP 1701da tinglaydigan narsa kerak — Linuxda xl2tpd yoki kl2tpd, Windowsda masofadan kirish xizmati — va o'rnatilgan, ammo to'xtatilgan xizmat klient tomondan tashlangan paketga xuddi o'xshaydi. O'zingiz tekshirgan qoidalarni qayta ochishdan oldin tinglovchini tekshiring. Keyin PPP muzokara qilishi kerak, birinchi LCP almashinuvi esa jimgina muvaffaqiyatsizlik odatda qo'nadigan joy.
Bu bosqichdagi bir tuzoq umuman tarmoq xatosi emas: Windows berilgan VPN turining bir vaqtda faqat bitta ulanishiga ruxsat beradi, shuning uchun ikkinchi urinish 937 xatosini qaytaradi, «bu turdagi boshqa ulanish ishlatilmoqda». Bu mahalliy qoida, undan aylanib o'tish yo'li esa boshqa qurilma, boshqa tunnel turi yoki allaqachon mavjud yagona ulanishni bo'lishish.
Taxmin qilish o'rniga bosqichlar tartibida jurnalni o'qing
Klientni to'xtating, qayta ishga tushiring va komponentlarni ular jurnal yozadigan tartibda o'qing. Ya'ni avval IPsec demoni — strongSwan yoki Libreswan, va ipsec --version qaysi biri ekanini aytadi — keyin L2TP demoni, keyin pppd. Xatolikdan oldin oxirgi bo'lib qaysi komponent yozgan bo'lsa, tekshiriladigan bosqichni belgilaydi, chunki tartibda undan keyin keladigan hech narsa umuman ishlamagan.
Saqlangan sessiya emas, yangi ulanish bilan tekshiring, chunki keshdan qayta ulanadigan klient almashinuvning ba'zi qismlarini o'tkazib yuborib, eskirgan natijani takrorlashi mumkin. Yetib borish, kalit almashinuvi, tunnel va PPPni birma-bir, shu tartibda tasdiqlang. Shunda yo'q so'rov jumboq bo'lishdan to'xtaydi va haqiqatan ishlash mumkin bo'lgan ro'yxatning ikkinchi satriga aylanadi. O'sha ro'yxatni tarmoq jamoasiga berasiz, aks holda ulardan ishga tushmagan demonda yashaydigan xatolik uchun tarmoq ekranini tekshirish so'ralardi.