VPNning qaysi bosqichi muvaffaqiyatsiz bo'ldi: IPsec, L2TP boshqaruvi yoki PPP autentifikatsiyasi
Oxirgi muvaffaqiyatli bosqichni toping va faqat shu qatlamni tuzating: IPsec, L2TP boshqaruv kanali, PPP autentifikatsiyasi yoki manzil berish.
Siz parolni o'zgartirdingiz va hech narsa qimirlamadi, chunki nosozlik hech qachon PPPda bo'lmagan. L2TP/IPsec beshta butunlay boshqacha topshirish uchun bitta ulanish xatosini xabar qiladi va har bir topshirishning o'z tuzatishi bor. Teskari yo'nalishda ishlang: oxirgi muvaffaqiyatli bosqichni toping va faqat undan keyingi narsani o'zgartiring. Quyidagi tartib qaysi dalillarni birinchi to'plashni ham belgilaydi.
To'rt savolga tartib bilan javob bering
Yangi urinishni majburlang, chunki ba'zi mijozlar profil uzilib qayta ulanmaguncha avvalgi xatoni ko'rsatib turadi. Keyin shunga javob bering: IPsec xavfsizlik assotsiatsiyasi bormidi, L2TP boshqaruv aloqasi va qo'ng'iroq paydo bo'ldimi, PPP autentifikatsiya hukmiga yetdimi va IPCP mijozga manzil berdimi? Birinchi yo'q — siz tuzatadigan bosqich. Undan keyingi hamma narsa tekshirilmagan, shuning uchun assotsiatsiya hech qachon bo'lmagan bo'lsa, rad etilgan foydalanuvchi nomi hech narsani isbotlamaydi.
Taqqoslashdan oldin ikkala uchdagi soatlarni sinxronlashtiring. IPsecni tozalab PPPda muvaffaqiyatsiz bo'lgan qayta urinish bitta nosozlikdek ko'rinadi, agar mijoz faqat oxirgi xabarni ko'rsatsa va server jurnali avvalgi urinishni saqlab tursa. Eng baland satr bo'yicha emas, vaqt belgisi bo'yicha o'qing.
Faqat foydalanuvchi ekran surati bo'lsa, eng arzon bo'linishga tayaning: noto'g'ri oldindan umumiy kalit va hech qachon javob bermaydigan xl2tpd Windows muloqot oynasida bir xil matn hosil qiladi, lekin biriga ikkala uchda o'zgartirilgan sir kerak, ikkinchisiga serverning o'zida ishga tushirilgan demon yoki xavfsizlik devori qoidasi kerak. O'rtadagi qurilma transport rejimidagi IPsec uni o'rab olgandan keyin ichki 1701ni tashlay olmaydi, shuning uchun yo'q yo'l filtrini qidirmang.
Har bir qatlam aslida nimaga egalik qiladi
IPsec ikki hamkor o'rtasidagi paketlarni himoya qiladi; L2TP o'sha himoyalangan yo'l ichida PPP seansini olib boradi, shuning uchun RFC 3193 o'z tunneliga emas, transport rejimiga buyruq beradi. Mijoz yorlig'i L2TP deydi, shuning uchun tunnel va kirish bitta mexanizmdek tuyuladi. Unday emas: L2TP boshqaruv aloqasi tunnel uchlarini joylashtirish uni yoqqan joyda autentifikatsiya qiladi, PPP esa server siyosatiga muvofiq foydalanuvchini alohida CHAP, PAP yoki MS-CHAPv2 bilan autentifikatsiya qiladi.
Bu bo'linish odamlar doim aralashtirib yuboradigan ikki sirni tushuntiradi. Oldindan umumiy kalit IPsec hamkorlarini autentifikatsiya qiladi. Foydalanuvchi nomi va parol foydalanuvchini PPP oldida aniqlaydi. Sertifikatlar bilan autentifikatsiya qiluvchi profilda Windows umumiy sirini qayta yozish muvaffaqiyatsiz bosqichda hech narsani o'zgartirmaydi, PPP parolini tahrirlash esa yetishmayotgan himoyalangan kanalni bera olmaydi. Xuddi shu vazminlik shaxsni tekshirishga ham tegishli: tunnel olish uchun hamkorning shaxsini yoki sertifikat tekshiruvini o'chirmang, chunki unda ulanadigan narsa yo'l, hamkor emas.
Autentifikatsiya ham PPPning oxiri emas. Foydalanuvchi qabul qilingandan keyin IPCP mijoz manzili va server berishga tayyor DNS va WINS variantlarini kelishadi. Mijoz CHAP yoki MS-CHAPv2dan o'tib ham manzilsiz qolishi mumkin, bu PPP ichidagi nosozlik, yo'naltirish muammosi emas. IPsecsiz oddiy L2TP haqiqiy va himoyasiz qoladi, shuning uchun muvaffaqiyatli ulanish trafik himoyalanganini hech qachon isbotlamaydi; server nimani talab qilishini tekshiring, mijoz yorlig'ini emas.
Birinchi yetishmayotgan bosqichdan qaror qiling
Jadvalni birinchi yetishmayotgan element bo'yicha chapdan o'ngga o'qing. O'ng ustun o'sha paytda arziydigan yagona ish; uning chap tomonidagi hamma narsa allaqachon isbotlangan va qayta sinash ma'lumot qo'shmasdan uzilish oynasini yoqib yuboradi.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Uch satr ogohlantirishga loyiq. 1701 satri NAT orqasidagi Windows mijozlari odatda qo'nadigan joy: assotsiatsiya tugaydi, keyin hech narsa kelmaydi va sabab yomon parol emas, inkapsulyatsiya. IPCP satri xato ravishda yo'l muammosi deb o'qiladigan satr, chunki Windows yetishmayotgan manzilni 720 xatosiga o'raydi va tray belgisi faqat ulanish muvaffaqiyatsiz bo'lganini aytadi; o'sha nosozlik autentifikatsiyadan keyin va yo'naltirishdan oldin turadi. Oxirgi satr umuman IPsec nosozligi emas, belgi uzilgan desa ham.
Qatlamlarni ajratadigan buyruqlar
strongSwan ishlaydigan Linux serverida swanctl --list-sas o'rnatilgan assotsiatsiyalarni hamkorning shaxsi bilan sanaydi, ipsec statusall esa eski strongSwan va libreswan xostlarini qamrab oladi. Uning ostida ip xfrm state yadroning haqiqiy assotsiatsiyalarini ko'rsatadi, ss -lunp | grep 1701 esa xl2tpd qayerga bog'langanini isbotlaydi. Boshqaruv aloqalari va qo'ng'iroqlar kelishini ko'rish uchun xl2tpd -D ni old planda ishga tushiring va taklif qilingan usul bilan javobni ko'rish uchun /etc/ppp/options.xl2tpd ichida pppd nosozlik tuzatishni yoqing.
Jurnallar muvaffaqiyatli autentifikatsiyani ko'rsatganda keyingi savol IPCP tugaganmi. /etc/xl2tpd/xl2tpd.conf faylining [lns default] bo'limidagi ip range da hali bo'sh manzillar bormi va mijoz kutayotgan bo'lsa /etc/ppp/options.xl2tpd haqiqatan ms-dns va ms-wins ni olib yuriyaptimi, tekshiring. Tugagan hovuz va yetishmayotgan DNS varianti simda boshqacha ko'rinadi: birinchisi mijozni manzilsiz va 720 bilan qoldiradi, ikkinchisi manzil beradi, lekin hal qiluvchi bermaydi, shuning uchun nomlar muvaffaqiyatsiz bo'ladi, xom manzillarga ping esa ishlaydi. Ikkalasi ham parolni qayta kiritish bilan tuzatilmaydi.
Mijozda NetworkManager L2TP plagin pppd suhbatini jurnalga yozadi, shuning uchun journalctl -u NetworkManager -b odatda tunnel tepada, autentifikatsiya rad etildi holatini umuman tunnel yo'q holatidan ajratadi. Windowsda Get-VpnConnection profilning haqiqiy autentifikatsiya sozlamalarini xabar qiladi va Event Viewerda Application ostidagi RasClient hodisalari muvaffaqiyatsiz komponentni nomlaydi. Muloqot oynasi juda noaniq bo'lsa, netsh ras set tracing * enable ni yoqing.
Tutib olishlar bitta ehtiyotni talab qiladi. Transport rejimidagi IPsec bilan ichki UDP 1701 shifrlangan, shuning uchun tashqi interfeysdagi tutib olish ESPni yoki NAT-T ostida UDP 4500ni ko'rsatadi va umuman L2TP ko'rsatmaydi. Tutib olishda 1701 yo'qligi kutilgan va yopiq portning isboti emas; ESP yoki 4500 hisoblagichlari qimirlayaptimi, kuzating.
NAT, MTU va yo'llar: stek sizni qayerda chalg'itadi
NAT biror narsa autentifikatsiya qilinishidan oldin taxminlarni buzadi. ESP o'z IP protokoli, shuning uchun tarjima qiluvchi qurilma hamkorlar inkapsulyatsiya qilmasa uni tashlaydi; aynan shuni UDP 4500 ta'minlaydi. O'zi uy routeri yoki bulut NAT darvozasi orqasida turgan Windows serverida IPsec bosqichi 789 xatosi bilan muvaffaqiyatsiz bo'ladi, PolicyAgent kaliti ostida AssumeUDPEncapsulationContextOnSendRule 2 ga qo'yilib mashina qayta ishga tushirilmaguncha va nosozlik yopiq portdan ajratilmay qoladi. NAT orqasidagi mijozlar osonroq: serverda umumiy manzil bo'lsa, UDP 4500 ustidagi NAT-T ularni olib boradi va bu qiymat ishtirok etmaydi.
PPP tepada bo'lgach, qora teshikli MTU o'lik tunnelni taqlid qiladi: kichik paketlar o'tadi, TLS qo'l berish yoki sahifa yuklanishi osilib qoladi va mijoz hali ulangan ko'rinishi mumkin. Serverni ayblashdan oldin interfeys MTUsini tushiring yoki darvozada MSSni siqing. Bo'lingan tunnel yo'naltirish boshqa firibgar; noto'g'ri niqob bilan yuborilgan quyi tarmoq tunnelni sog'lom va bitta ilovani yetib bo'lmaydigan qilib qoldiradi. Xususiy xost nomi o'z qadamini qo'shadi: agar so'rov mahalliy hal qiluvchi orqali chiqsa, nom har qanday yo'l sinalishidan oldin hal qilinmaydi.
Ishonch ma'lumotlariga tegishdan oldin tekshiruv ro'yxati
Ro'yxatni tartib bilan bajaring va birinchi muvaffaqiyatsiz elementda to'xtang. Har qadam arzon va har biri tahrirlarning butun sinfini chiqarib tashlaydi.
- Assotsiatsiya ikkala uchda borligini tasdiqlang, ulangan yorlig'i bilan emas, hamkorning shaxsi bilan moslashtirilgan.
- UDP 1701 xl2tpdga yetib borishini tasdiqlang; qo'ng'iroqsiz assotsiatsiya sizning nosozligingiz.
- Parol noto'g'ri deb hisoblashdan oldin PPP hukmini va autentifikatsiya qilgan bo'lsa IPCP natijasini o'qing.
- Endi ishonch ma'lumotlarini server kutgan shaklda qayta kiriting, chunki domen prefiksi hisobni o'zgartiradi.
- Agar hali ham muvaffaqiyatsiz bo'lsa, ikkala uchni tekislangan vaqt belgilari bilan tutib oling va bosqichma-bosqich taqqoslang.
Ikkinchi qadamda to'xtash yo'l yoki inkapsulyatsiya muammosini bildiradi va hech qanday parol tahriri uni qimirlatmaydi. Uchinchi qadamda to'xtash jurnal tuzatiladigan usul yoki manzil hovuzini allaqachon nomlaganini bildiradi. Har holda keyingi o'zgarish asoslay oladigan o'zgarishingizdir va hech qachon ishtirok etmagan sozlamalar orasida aylanmaysiz.