L2TP/IPsec uğursuz olur: IPsec, tunel autentifikasiyası və ya PPP girişini ayırın

Bir L2TP/IPsec bağlantısının içində üç şey autentifikasiya edir və bunlardan yalnız biri daxil olan şəxsi aid edir. IPsec tunelin uclarını təsdiqləyir, L2TP idarə bağlantısı tərəfləri öz sirri ilə yenidən təsdiqləyə bilər, sonra PPP sessiya içindəki istifadəçi hesabını təsdiqləyir. Hər hansı mərhələdə uğursuzluq müştəri pəncərəsində ümumi giriş xətası kimi görünür və server jurnalında tamam fərqli görünür. Mərhələləri ardıcıl keçin və uğursuz olan birincidə dayanın, çünki yoxlanılmamış mərhələnin altındakı hər mərhələ də yoxlanılmamışdır.

Üç autentifikasiya mərhələsi, üç fərqli kimlik

IPsec ucların kimə aid olduğunu əvvəlcədən paylaşılmış açar və ya sertifikatla təsdiqləyir. Bu kimlik maşınlara və ya şlüzlərə aiddir, heç vaxt klaviatura arxasındakı insana aid deyil. Tərəflər bu mərhələdə razılaşa bilmədikdə, heç bir L2TP paketi mübadilə olunmur.

L2TP idarə bağlantısı hər iki ucun saxlamalı olduğu ortaq sirrlə idarə olunan ikinci, ayrı çağırış-cavab mübadiləsi əlavə edə bilər.

RFC 2661 bu idarə-bağlantısı autentifikasiyasını könüllü edir, bu da eyni səhvin iki serverdə niyə fərqli simptomlar yaratdığını izah edir. Heç vaxt tunel sirri qurmayan quraşdırma bu mərhələni tamamilə keçir; sirri yalnız bir tərəfdə quran quraşdırma isə PPP heç təklif olunmadan uğursuz olur. Sonra PPP istifadəçini PAP, CHAP və ya MSCHAPv2 ilə autentifikasiya edir və adı yerli ola bilən, chap-secrets içində olan və ya RADIUS üzərində olan hesab anbarına verir. Bu nöqtədə yanlış parol sizi hələ də işləyən tunel və uğursuz sessiya ilə qoyur.

Konfiqurasiyanı redaktə etməzdən əvvəl dayanma nöqtəsini oxuyun

Əvvəlcə ipsec --version işə salın ki, status çıxışının strongSwan-a yoxsa Libreswan-a aid olduğunu biləsiniz. Sonra müştəri pəncərəsini deyil, server jurnalını oxuyun, çünki hansı mərhələnin imtina etdiyini server qeyd edir.

Adətən bir sətir bileti həll edir: IKE və ya təklif şikayəti birinci mərhələdir, idarə bağlantısı mesajı ikinci mərhələdir, PPP metodu və ya hesab rəddi isə üçüncü mərhələdir. Həmin sətri vaxt damğası ilə bilete köçürün. Müştəri tərəfindən təxmin etmək artıq əlinizdə olan yeganə sübutu xərcləyir.

Açar materialını və parolları həmin köçürmədən kənarda saxlayın; mərhələ adı işi istiqamətləndirir və sızmış əvvəlcədən paylaşılmış açar bileti daha pis nəticələrlə yenidən açır.

Birinci addım: IPsec-in assosiasiyası varmı?

strongSwan üzərində ipsec statusall, Libreswan üzərində isə ipsec whack --status işə salın və sıfırdan fərqli sayğaclarla qurulmuş uşaq assosiasiyası axtarın. ip xfrm state hər ikisində nüvə görünüşünü göstərir. Sayğacları artan quraşdırılmış SA cütü birinci mərhələnin bitdiyini və davam edə biləcəyinizi bildirir.

Heç bir assosiasiyanın olmaması tərəf ünvanına, təklif dəstinə və ya əvvəlcədən paylaşılmış açara işarə edir, bəzən də UDP 500-ü yenidən yazıb UDP 4500-ü atan cihaza. Qurulub bir neçə saniyə sonra yox olan assosiasiya adətən etimad problemi deyil, iki uc arasında ömür uyğunsuzluğudur. Hər hansı bir şeyi yenidən yazmazdan əvvəl hər iki tərəfin eyni şifrələmə və heş təkliflərini sadaladığını yoxlayın. Yoxdursa, heç bir açar heç vaxt işləməyəcək.

Assosiasiya yox ikən dayanın. Bu nöqtədə PPP seçimlərini redaktə etmək heç nəyi dəyişmir və əsl nasazlığı növbəti şəxsdən gizlədir.

İkinci addım: L2TP idarə bağlantısı autentifikasiya oldumu?

IPsec qalxdıqdan sonra L2TP demonunu qurulmuş vəziyyətə çatan idarə bağlantısı üçün izləyin, çünki PPP bundan əvvəl başlaya bilməz. İdarə bağlantısında imtina tunel sirrinin uclar arasında fərqli olduğunu və ya bir ucun digərinin heç göndərmədiyi sirri tələb etdiyini göstərir. Müştərilər çox vaxt ortaq sirr adlanan tək bir sahə göstərir və bu, adətən L2TP-yə deyil, IPsec-ə aiddir. Onu doldurmaq tunel sirrini qurmur, silmək isə onu söndürmür.

Heç bir tərəfdə tunel sirri qurulmayıbsa, bu mərhələni keçin və idarə bağlantısı uğursuzluğunu əvəzində çatımlılıq kimi qəbul edin. UDP 1701-in demona çatdığını və hər iki tərəfin eyni inkapsulyasiyada razılaşdığını təsdiqləyin. Bu iki şərtdən biri üçün yazılmış firewall qaydası yarım açılan bağlantının ümumi səbəbidir.

Yalnız PPP danışıqlarına başlayan sessiya tunel mərhələsini həqiqətən keçmişdir.

Üçüncü addım: PPP hesabı rədd edirmi?

PPP uğursuzluğu kənardan fərqli görünür: tunel qurulub, sessiya başlayır və demon autentifikasiya metodu uğursuzluğu və ya hesab rəddi qeyd edir. Həmin mesajda adı çəkilən metodu oxuyun. PAP və CHAP fərqli səbəblərdən uğursuz olur və birini rədd edən server yalnız onu təklif edən müştərini rədd edəcək.

Linux serverdə demonun PPP-yə ötürdüyü seçimlər faylını, adətən /etc/ppp/options.xl2tpd, yoxlayın və hansı metodların qəbul edildiyini və hesabların harada həll olunduğunu təsdiqləyin. RADIUS-da olub yerli sirlər faylında olmayan ad təmiz şəkildə uğursuz olur və pis parol kimi görünür. Sonra müştərinin serverin qəbul etdiyi metodu təklif etdiyini yoxlayın, serverin danışıqdan imtina etdiyi daha güclü metodu deyil. Bu mərhələni düzəltmək üçün əvvəlcədən paylaşılmış açarı dəyişmək bir günortanı xərcləyir və heç nəyi dəyişmir.

Sessiya nəhayət qalxdıqda, ünvan təyini, DNS və marşrutlar hələ yoxlanılmayıb və hər biri öz üsulu ilə sakitcə uğursuz olur. Qeydlərinizdə üç qatı ayrı saxlayın: düzgün açar yanlış hesabla həmişə uğursuz olur və bir qatın təmiri heç vaxt başqa qatı təmir etmir.