L2TP NO_PROPOSAL_CHOSEN: aslida qaysi bosqich muvaffaqiyatsiz bo'ldi?
Bildirishnoma taklif rad etilganini aytadi, qaysi birini emas. Bosqichni aniqlash uchun backend jurnalini o'qing, so'ng to'plamlarni gatewayni boshqaradigan kishi bilan solishtiring.
NO_PROPOSAL_CHOSEN har qanday PPP foydalanuvchi nomi tekshirilishidan oldin keladi, bu foydali fakt va shu bilan birga xabar nega chalg'itishining sababidir. U bir tomon taklifni rad etganini bildiradi; qaysi parametr mos kelmaganini bildirmaydi va rad etish IKE assotsiatsiyasi qurilayotganda bo'ldimi yoki keyinroq trafik himoyasi bo'yicha muzokaralar paytida bo'ldimi, bu haqda hech narsa demaydi. Bu ikki imkoniyat ortida ikki xil tuzatish turadi va ulardan faqat bittasi odamlar birinchi murojaat qiladigan PFS katakchasiga tegishli.
Bitta xabar, ikkita taklif to'plami
IKEv1 L2TP/IPsec tartibida ikkita muzokara ketma-ket bo'ladi. 1-bosqich IKE xavfsizlik assotsiatsiyasini shifrlash algoritmi, yaxlitlik algoritmi va Diffie-Hellman guruhidan quradi. So'ngra 2-bosqich trafik qanday himoyalanishini kelishadi va PFS talabi aynan o'sha ikkinchi suhbatga tegishli.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Bosqichlar ketma-ket bo'lgani uchun, nosozlik joyi qaysi ro'yxatni solishtirishni aytadi. Xabarning butun diagnostik qiymati shunda va buni biron sozlamaga tegishdan oldin ajratib olishga arziydi.
Nega PFS katakchasi 1-bosqichni tuzata olmaydi
PFSni o'chirish 2-bosqichning xususiyatini o'zgartiradi. Agar tomonlar 1-bosqich bo'yicha hech qachon kelishmagan bo'lsa, ESP suhbati umuman bo'lmaydi, shuning uchun katakcha rad etishga hech qanday ta'sir qilmaydi va shu sababli uni almashtirish xuddi shu xatoni boshqa vaqt belgisi bilan beradi.
Teskari xato ham shunchalik keng tarqalgan. Muvaffaqiyatli IKE assotsiatsiyasi ESP taklifi maqbul ekanini isbotlamaydi va 2-bosqich guruhi mos kelishini mutlaqo isbotlamaydi. O'rnatilgan boshqaruv tunneliga faqat 1-bosqich haqidagi dalil sifatida qarang. Odamlar yashil qatorni «tunnel ishlayapti» deb o'qiydi, so'ng ikkinchi muzokara boshlanmaganini hech kim aytmaganligi uchun noto'g'ri bosqichda bir soat o'tkazadi.
Algoritmlarni tanlashdan oldin jurnalni o'qing
Rad etishdan bevosita oldingi xabarlarni ulanishni haqiqatda xizmat qiladigan backenddan to'plang va ularni o'sha urinish bilan bog'lang. Bu bog'liqliksiz siz boshqa ulanish tarixini o'qib, undan xulosa chiqarayapsiz.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanO'sha qatorlardan ikkita savolga javob bering: 1-bosqich assotsiatsiyasi o'rnatildimi va qaysi almashinuv muvaffaqiyatsiz bo'ldi. Bu ikki javob qidiruvni bitta atributlar ro'yxatiga toraytiradi. Atrofida kontekstsiz yalang'och bildirishnoma buni qila olmaydi, forum mavzusidan taklifni sinab ko'rish qanchalik jozibali bo'lmasin. Boshqa backendli mashinadan ishlaydigan satrni nusxalash odatda bitta rad etishni boshqasi bilan almashtiradi, biroz keyinroq.
Backend sintaksisi sayohat qilmaydi
Biror narsani solishtirishdan oldin NetworkManager-l2tp versiyasini va IPsec backend versiyasini yozib oling. Libreswan va strongSwan na taklif sintaksisini, na bir xil algoritm to'plamlarini bo'lishadi, shuning uchun birida ishlaydigan satr ikkinchisida sintaksis xatosi. O'rnatilgan backend siyosat bo'yicha IKEv1ni ham rad etishi mumkin va unda hech qanday taklif hech qachon qabul qilinmaydi.
Loyihaning README fayli o'sha backend farqlarini hujjatlashtiradi va 1-bosqich hamda 2-bosqich maydonlarini alohida saqlaydi. Uni tuzilma hujjati sifatida o'qing, har bir tarixiy shifrni va zaif guruhni yoqish taklifi sifatida emas, chunki faqat shu yo'l bilan muvaffaqiyat qozonadigan ulanish sizdan qurish so'ralgan ulanish emas.
To'plam bo'yicha kelishing, so'ng bosqichlarni tekshiring
Gateway operatoridan qaysi IKE va ESP to'plamlari qo'llab-quvvatlanishi va tasdiqlanganini so'rang, so'ng bu javobni mijozning konfiguratsiya fayli bilan emas, haqiqiy takliflari bilan solishtiring. Agar kelishmovchilik xususan 2-bosqich PFSiga tegishli bo'lsa, qo'llab-quvvatlanadigan guruh yoki aniq tasdiqlangan PFSsiz siyosat ustida to'xtang. Siyosatni xato nomidan xulosa qilmang.
Yagona kesishuv tashkilot endi qabul qilmaydigan kriptografiyani talab qilsa, qaror gatewayga yoki protokol migratsiyasiga tegishli. Mijoz satrini biror narsa kelishgunga qadar kengaytirish — ma'lum zaiflikni yonida yashil belgi bilan yetkazib berish usuli.
Haqiqiy nomuvofiqlikni tuzatgandan so'ng, L2TP va PPPni tekshirishdan oldin IPsec o'rnatilganini tasdiqlang va keyingi har qanday autentifikatsiya rad etishini keyingi bosqichga tegishli deb hisoblang. So'ng yangilanishni tasdiqlangan sinov jarayonida sinab ko'ring, chunki birinchi assotsiatsiyaning o'rnatilishi uning qolgan umri haqida hech narsa demaydi.