L2TP NO_PROPOSAL_CHOSEN: əslində hansı mərhələ uğursuz oldu?
Bildiriş bir təklifin rədd edildiyini deyir, hansının olduğunu yox. Mərhələ üçün backend jurnalını oxuyun, sonra dəstləri şlüzü idarə edənlərlə müqayisə edin.
NO_PROPOSAL_CHOSEN hər hansı PPP istifadəçi adı yoxlanmadan əvvəl gəlir ki, bu faydalı faktdır və eyni zamanda mesajın niyə yanıltıcı olduğunun səbəbidir. O, bir tərəfin təklifi rədd etdiyini bildirir; hansı parametrin uyğunsuz olduğunu bildirmir və rəddin IKE assosiasiyası qurularkən, yoxsa sonra trafik mühafizəsi üzərində danışıqlar aparılarkən baş verdiyini də demir. Bu iki ehtimalın arxasında iki fərqli düzəliş dayanır və onlardan yalnız biri insanların ilk müraciət etdiyi PFS işarələmə qutusuna aiddir.
Bir mesaj, iki təklif dəsti
IKEv1 L2TP/IPsec quruluşunda ardıcıl iki danışıq var. Mərhələ 1 şifrələmə alqoritmi, bütövlük alqoritmi və Diffie-Hellman qrupundan IKE təhlükəsizlik assosiasiyasını qurur. Sonra mərhələ 2 trafikin necə qorunacağını danışır və PFS tələbi həmin ikinci söhbətə aiddir.
| 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 |
Mərhələlər ardıcıl olduğu üçün uğursuzluğun yeri hansı siyahını müqayisə edəcəyinizi deyir. Mesajdakı bütün diaqnostik dəyər budur və hər hansı parametrə toxunmazdan əvvəl onu çıxarmağa dəyər.
Niyə PFS işarələmə qutusu mərhələ 1-i düzəldə bilməz
PFS-i söndürmək mərhələ 2 xassəsini dəyişir. Tərəflər mərhələ 1-də heç vaxt razılaşmayıbsa, ESP söhbəti heç baş vermir, buna görə işarələmə qutusunun rəddə heç bir təsiri yoxdur və buna görə onu dəyişdirmək eyni xətanı başqa vaxt damğası ilə verir.
Əks səhv də eyni dərəcədə geniş yayılıb. Uğurlu IKE assosiasiyası ESP təklifinin məqbul olduğunu sübut etmir və mərhələ 2 qrupunun uyğun olduğunu qətiyyən sübut etmir. Qurulmuş idarəetmə tunelini yalnız mərhələ 1 haqqında sübut kimi qəbul edin. İnsanlar yaşıl sətri «tunel işləyir» kimi oxuyur, sonra ikinci danışığın başlamadığını heç nə demədiyi üçün bir saatı səhv mərhələdə keçirirlər.
Alqoritmləri seçməzdən əvvəl jurnalı oxuyun
Rəddən dərhal əvvəlki mesajları əlaqəni həqiqətən idarə edən backend-dən toplayın və onları eyni cəhdlə əlaqələndirin. Bu əlaqələndirmə olmadan başqa əlaqənin tarixçəsini oxuyur və ondan nəticə çıxarırsınız.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanHəmin sətirlərdən iki suala cavab verin: mərhələ 1 assosiasiyası quruldumu və hansı mübadilə uğursuz oldu. Bu iki cavab axtarışı bir atribut siyahısına daraldır. Ətraf konteksti olmayan çılpaq bildiriş bunu edə bilməz, hərçənd forum mövzusundan bir təklif sınamaq çox cəlbedici olsa da. Fərqli backend-i olan maşından işləyən sətri kopyalamaq adətən bir rəddi bir az sonra gələn digəri ilə əvəz edir.
Backend sintaksisi daşınmır
Hər şeyi müqayisə etməzdən əvvəl NetworkManager-l2tp versiyasını və IPsec backend versiyasını qeyd edin. Libreswan və strongSwan təklif sintaksisini və eyni alqoritm dəstlərini paylaşmır, buna görə birində işləyən sətir digərində sintaksis xətasıdır. Quraşdırılmış backend siyasətinə görə IKEv1-i də rədd edə bilər və bu halda heç bir təklif heç vaxt qəbul olunmayacaq.
Yuxarı axın README sənədi bu backend fərqlərini sənədləşdirir və mərhələ 1 ilə mərhələ 2 sahələrini ayrı saxlayır. Onu struktur sənədi kimi oxuyun, hər tarixi şifri və zəif qrupu aktivləşdirmək üçün dəvət kimi yox, çünki yalnız bunu etməklə uğur qazanan əlaqə sizdən qurmaq istənilən əlaqə deyil.
Dəst üzərində razılaşın, sonra mərhələləri yoxlayın
Şlüz operatorundan hansı IKE və ESP dəstlərinin dəstəkləndiyini və təsdiqləndiyini soruşun, sonra bu cavabı müştərinin konfiqurasiya faylı ilə deyil, faktiki təklifləri ilə müqayisə edin. Fikir ayrılığı xüsusi olaraq mərhələ 2 PFS ilə bağlıdırsa, dəstəklənən qrup və ya açıq şəkildə təsdiqlənmiş PFS-siz siyasət üzərində dayanın. Siyasəti xətanın adından çıxarmayın.
Yeganə kəsişmə təşkilatın artıq qəbul etmədiyi kriptoqrafiya tələb edəndə qərar şlüzə və ya protokol miqrasiyasına aiddir. Müştəri sətrini nə isə danışıqlar aparana qədər genişləndirmək məlum zəifliyi yanında yaşıl işarə ilə göndərməyin yoludur.
Həqiqi uyğunsuzluğu düzəltdikdən sonra L2TP və PPP-ni araşdırmadan əvvəl IPsec qurulduğunu təsdiqləyin və sonrakı istənilən autentifikasiya rəddini növbəti mərhələyə aid hesab edin. Sonra yenilənməni təsdiqlənmiş sınaq prosesində yoxlayın, çünki ilk assosiasiyanın qurulması onun qalan ömrü haqqında heç nə demir.