PPTP və L2TP/IPsec niyə istifadəçi adı sorğusundan əvvəl dayanır?

İstifadəçi adı sorğusunun olmaması diaqnostik hədiyyədir: PPP hələ başlamayıb, yəni hesaba, parola və domen siyasətinə hələ müraciət edilməyib. PPTP və ya L2TP/IPsec bağlantısında klient etimad məlumatlarını yalnız tunel mövcud olduqdan və server PPP sessiyasına başladıqdan sonra soruşur. O ana qədər uğursuz ola bilən hər şey daşıma, açar mübadiləsi və ya tunel quruluşudur ki, bu da «VPN xarabdır» anlayışından qat-qat kiçik bir sahədir.

Çatışmayan sorğu nasazlığı üç mərhələyə yığır

Görünən şəkildə sonuncu hansı mərhələnin uğur qazandığını yazın, çünki hər birinin sahibi və düzəlişi fərqlidir. İki mərhələ əvvəl ilişib qalmışkən hesab parametrlərini təxmin etmək bir günortanın yoxa çıxma üsuludur.

Sorğu olmadan vaxtı bitən klient heç vaxt IPsec assosiasiyası almır, deməli nasazlıq IKE-də və ya paketlərinizin şlüzə ümumiyyətlə çatmasındadır. Etimad məlumatlarının yoxlanıldığını bildirib sonra düşən klient mesajın ima etdiyindən daha irəli gedib. Sorğudan sonra rədd gəlirsə bu PPP autentifikasiyasıdır və onun yeri bu məqalə deyil, hesab məqaləsidir.

Birinci mərhələ: firewall-un səssizcə atdığı protokol

PPTP idarə kanalı üçün TCP 1723, məlumat yolu üçün isə IP protokolu 47 tələb edir və ikisi ayrı-ayrı səyahət edir. Bir çox şəbəkə 1723-ü ötürür, 47 protokolunu isə atır; nəticədə razılaşan, amma heç nə daşımayan tunel yaranır. NAT edən marşrutlaşdırıcıya GRE dəstəkli keçid də lazımdır və yalnız IPv6 üzərində işləyən giriş yolu heç bir konfiqurasiyada PPTP daşıya bilməz.

IPsec üzərindən L2TP IKE üçün 500, NAT traversliyi üçün 4500 portunu xərcləyir, sonra L2TP trafikinin özünü 1701-ə bükür; assosiasiya yarandıqdan sonra qorunan yükü ESP daşıyır. İki idarə portuna icazə verib ESP-ni verməsəniz, başlıqdakı simptomun eynisini alırsınız: görünən irəliləyiş, sonra etimad məlumatları pəncərəsindən əvvəl ölü klient. Telefon hotspot-undan sınaq klient problemini yol problemindən ayırmağın ucuz üsuludur.

İkinci mərhələ: açar olmayan açar, təklif edilməyən təklif

Uyğunsuz əvvəlcədən paylaşılan açar tez və səssizcə uğursuz olur; adi variant ekranda düzgün görünən, amma yapışdırılmış sətir keçidi və ya sonunda boşluq daşıyan açardır. Linux klientində dialoq mütləq həqiqət mənbəyi deyil: NetworkManager-in L2TP plaqini sirləri /etc/ipsec.d/ altındakı fayllarda saxlayır və /etc/ipsec.secrets hələ də daxil etdiyi köhnə bir bağlantı faylı sizin indicə yazdığınızın yerinə istifadə olunacaq. Həmin faylı etibarlı yerə köçürün, daxiletmə yolundan çıxarın, sonra açarı əl ilə yenidən yazın.

Bu mərhələnin digər yarısı təklifdir. Hər iki tərəf eyni 1-ci faza alqoritm dəsti — şifrələmə, bütövlük və Diffie-Hellman qrupu — və 2-ci faza üçün uyğun ESP çevrilmələri barədə razılaşmalıdır, əks halda assosiasiya ümumiyyətlə yaranmır. Yalnız 3DES, SHA1 və MODP1024 təklif edən şlüz daha güclü alqoritmlər üçün qurulmuş klienti rədd edəcək və jurnalı rədd edilən çevrilmənin adını çəkəcək. Jurnalı oxusanız uyğunsuzluğun adını çəkir; xidməti yenidən işə salmaq isə heç nə öyrətmir. Forum mövzusundan alqoritm sətri köçürmək əvəzinə şlüzdən həqiqətən hansı çevrilmələri razılaşdıracağını soruşun: ünvanına yönəldilmiş ike-scan razılaşacağı çevrilmələri qaytarır. Əgər yeganə təklif siyasətinizin artıq icazə vermədiyi kriptoqrafiyadırsa, düzəliş klientin aşağı salınmasında deyil, şlüzdə olmalıdır.

Windows-da açar və autentifikasiya üsulu VPN profilində yaşayır və uyğunsuzluq etimad məlumatları sorğusundan sonra deyil, əvvəl üzə çıxır. Qəbul edən tərəf Windows Server olduqda, uzaqdan giriş rolunun quraşdırıldığını, sertifikatın klientlərin qoşulduğu adla uyğunlaşdığını və heç bir port filtrinin yuxarıdakı protokollardan dar olmadığını təsdiqləyin.

Üçüncü mərhələ: tunel var, PPP heç başlamır

IKE tamamlandıqda və sorğu hələ də görünmədikdə, firewall-a deyil, tunel demonuna baxın. L2TP UDP 1701-də dinləyən bir şey tələb edir — Linux-da xl2tpd və ya kl2tpd, Windows-da uzaqdan giriş xidməti — və quraşdırılıb dayandırılmış xidmət klient tərəfindən atılmış paketlə eyni görünür. Artıq yoxladığınız qaydaları yenidən açmazdan əvvəl dinləyicini yoxlayın. Sonra PPP razılaşmalıdır və ilk LCP mübadiləsi səssiz uğursuzluğun adətən düşdüyü yerdir.

Bu mərhələdə bir tələ heç də şəbəkə nasazlığı deyil: Windows eyni vaxtda verilmiş VPN növündən yalnız bir bağlantıya icazə verir, ona görə ikinci cəhd 937 xətasını qaytarır: «bu növdən başqa bağlantı istifadə olunur». Bu yerli qaydadır və onun ətrafından başqa cihaz, başqa tunel növü və ya artıq mövcud olan tək bağlantını paylaşmaqla keçmək olar.

Jurnalı təxmin etmək əvəzinə mərhələ sırası ilə oxuyun

Klienti dayandırın, yenidən başladın və komponentləri jurnal yazdıqları sıra ilə oxuyun. Yəni əvvəlcə IPsec demonu — strongSwan və ya Libreswan, ipsec --version hansı olduğunu deyir — sonra L2TP demonu, sonra pppd. Nasazlıqdan əvvəl ən son hansı komponent yazıbsa, araşdırılacaq mərhələni o göstərir, çünki ardıcıllıqda ondan sonra gələn heç nə ümumiyyətlə işləməyib.

Yadda saxlanmış sessiya ilə deyil, təzə bağlantı ilə yoxlayın, çünki keşdən yenidən qoşulan klient mübadilənin hissələrini atlaya və köhnə nəticəni təkrarlaya bilər. Əlçatımı, açar mübadiləsini, tuneli və PPP-ni bir-bir, bu sıra ilə təsdiqləyin. Onda çatışmayan sorğu sirr olmaqdan çıxıb əslində üzərində işləyə biləcəyiniz siyahının ikinci sətrinə çevrilir. Bu siyahı həm də şəbəkə komandasına verdiyiniz siyahıdır; əks halda onlardan başlamamış demonda yaşayan nasazlıq üçün firewall-u yoxlamaq istəniləcək.