Hansı VPN mərhələsi uğursuz oldu: IPsec, L2TP nəzarəti və ya PPP autentifikasiyası

Şifrəni dəyişdiniz və heç nə dəyişmədi, çünki nasazlıq heç vaxt PPP-də deyildi. L2TP/IPsec beş tamamilə fərqli ötürmə üçün bir əlaqə xətası bildirir və hər ötürmənin öz bərpası var. Əvəzində tərsinə işləyin: uğurla keçən son mərhələni tapın və yalnız ondan sonra gələni dəyişin. Aşağıdakı sıra həm də ilk hansı sübutları toplayacağınızı müəyyən edir.

Dörd suala ardıcıllıqla cavab verin

Təzə cəhd məcbur edin, çünki bəzi müştərilər profil ayrılıb yenidən qoşulana qədər əvvəlki xətanı göstərməyə davam edir. Sonra buna cavab verin: IPsec təhlükəsizlik assosiasiyası varmı, L2TP nəzarət bağlantısı və çağırış göründümü, PPP autentifikasiya qərarına çatdımı və IPCP müştəriyə ünvan verdimi? İlk yox düzəldəcəyiniz mərhələdir. Ondan sonrakı hər şey sınaqdan keçməyib, ona görə assosiasiya heç vaxt olmayıbsa, rədd edilmiş istifadəçi adı heç nəyi sübut etmir.

Müqayisədən əvvəl hər iki tərəfdə saatları uyğunlaşdırın. IPsec-i təmizləyib PPP-də uğursuz olan cəhd, müştəri yalnız son mesajı göstərdikdə və server jurnalı əvvəlki cəhdi saxladıqda tək nasazlıq kimi görünür. Ən uca sətrə görə deyil, vaxt damğasına görə oxuyun.

Əlinizdə yalnız istifadəçinin ekran şəkli olduqda ən ucuz bölgüyə güvənin: səhv əvvəlcədən paylaşılmış açar və heç cavab verməyən xl2tpd Windows dialoqunda eyni mətni yaradır, lakin biri hər iki tərəfdə dəyişdirilməli sirr tələb edir, digəri serverin özündə demonun işə salınmasını və ya firewall qaydasını tələb edir. Ortadakı cihaz daxili 1701-i transport rejimli IPsec onu bükəndən sonra ata bilməz, ona görə olmayan yol filtri axtarmayın.

Hər qat əslində nəyə sahibdir

IPsec iki peer arasında paketləri qoruyur; L2TP həmin qorunan yolun içində PPP sessiyası daşıyır, buna görə RFC 3193 öz tuneli əvəzinə transport rejimini təyin edir. Müştəri etiketi L2TP deyir, ona görə tunel və giriş bir mexanizm kimi hiss olunur. Belə deyil: L2TP nəzarət bağlantısı yerləşdirmə onu aktivləşdirdiyi yerdə tunel son nöqtələrini autentifikasiya edir, PPP isə istifadəçini server siyasətinə uyğun olaraq CHAP, PAP və ya MS-CHAPv2 ilə ayrıca autentifikasiya edir.

Bu bölgü insanların qarışdırdığı iki sirri izah edir. Əvvəlcədən paylaşılmış açar IPsec peer-lərini autentifikasiya edir. İstifadəçi adı və şifrə istifadəçini PPP-yə tanıdır. Sertifikatlarla autentifikasiya edən profildə Windows-un paylaşılmış sirrini yenidən yazmaq uğursuz mərhələdə heç nəyi dəyişmir və PPP şifrəsini redaktə etmək çatışmayan qorunan kanalı verə bilməz. Eyni təmkin şəxsiyyət yoxlamasına da aiddir: tunel almaq üçün peer şəxsiyyətini və ya sertifikat yoxlamasını söndürməyin, çünki o zaman qoşulan peer deyil, yoldur.

Autentifikasiya da PPP-nin sonu deyil. İstifadəçi qəbul edildikdən sonra IPCP müştəri ünvanını və serverin verməyə hazır olduğu DNS və WINS seçimlərini razılaşdırır. Müştəri CHAP və ya MS-CHAPv2-dən keçib yenə ünvansız qala bilər ki, bu, marşrut problemi deyil, PPP daxilində nasazlıqdır. IPsec-siz sadə L2TP etibarlı və qorunmamış qalır, ona görə uğurlu qoşulma trafikin qorunduğunu heç vaxt sübut etmir; müştəri etiketinə deyil, serverin nə tələb etdiyinə baxın.

İlk çatışmayan mərhələyə görə qərar verin

Cədvəli ilk çatışmayan bəndə görə soldan sağa oxuyun. Sağdakı sütun həmin anda etməyə dəyər yeganə işdir; onun solundakı hər şey artıq sübut olunub və onu yenidən sınamaq məlumat əlavə etmədən kəsinti pəncərəsini yandırır.

Üç sətir xəbərdarlığa layiqdir. 1701 sətri NAT arxasındakı Windows müştərilərinin adətən düşdüyü yerdir: assosiasiya tamamlanır, sonra heç nə gəlmir və səbəb pis şifrə deyil, inkapsulyasiyadır. IPCP sətri marşrut problemi kimi səhv oxunan sətirdir, çünki Windows çatışmayan ünvanı 720 xətasına bürüyür və tepsi ikonu yalnız qoşulmanın uğursuz olduğunu deyir; bu nasazlıq autentifikasiyadan sonra və marşrutlaşdırmadan əvvəl yerləşir. Son sətir heç də IPsec nasazlığı deyil, baxmayaraq ki, tepsi ikonu əlaqənin kəsildiyini deyir.

Qatları ayıran əmrlər

strongSwan işləyən Linux serverində swanctl --list-sas qurulmuş assosiasiyaları peer şəxsiyyəti ilə sadalayır və ipsec statusall köhnə strongSwan və libreswan hostlarını əhatə edir. Altda ip xfrm state kernelin faktiki assosiasiyalarını göstərir, ss -lunp | grep 1701 isə xl2tpd-nin haraya bağlandığını sübut edir. Nəzarət bağlantılarını və çağırışları görüb izləmək üçün xl2tpd -D əmrini ön planda işə salın və təklif olunan metodu və cavabı görmək üçün /etc/ppp/options.xl2tpd faylında pppd sazlamağını aktivləşdirin.

Jurnallar uğurlu autentifikasiya göstərdikdən sonra növbəti sual IPCP-nin tamamlanıb-tamamlanmadığıdır. /etc/xl2tpd/xl2tpd.conf faylının [lns default] bölməsindəki ip range hələ boş ünvanlar saxlayırmı və müştəri gözləyirsə, /etc/ppp/options.xl2tpd həqiqətən ms-dns və ms-wins daşıyırmı, yoxlayın. Tükənmiş hovuz və çatışmayan DNS seçimi naqildə fərqli görünür: birinci müştərini ünvansız və 720 ilə qoyur, ikincisi ünvan verir amma resolver vermir, ona görə adlar uğursuz olur, xam ünvanlara ping isə işləyir. Heç biri şifrəni yenidən daxil etməklə düzəlmir.

Müştəridə NetworkManager L2TP plagini pppd söhbətini jurnala yazır, ona görə journalctl -u NetworkManager -b adətən tunel qalxıb, autentifikasiya rədd edilib vəziyyətini heç tunel yoxdur vəziyyətindən ayırır. Windows-da Get-VpnConnection profilin həqiqi autentifikasiya parametrlərini bildirir və Event Viewer-də Application altındakı RasClient hadisələri uğursuz komponenti adlandırır. Dialeq çox qeyri-müəyyən olduqda netsh ras set tracing * enable əmrini aktivləşdirin.

Tutmalar bir ehtiyat tələb edir. Transport rejimli IPsec ilə daxili UDP 1701 şifrələnir, ona görə xarici interfeysdə tutma ESP və ya NAT-T altında UDP 4500 göstərir və heç L2TP göstərmir. Tutmada 1701-in olmaması gözləniləndir və bağlı portun sübutu deyil; ESP və ya 4500 sayğaclarının hərəkət edib-etmədiyinə baxın.

NAT, MTU və marşrutlar: yığın sizi harda çaşdırır

NAT hər hansı autentifikasiyadan əvvəl fərziyyələri pozur. ESP öz IP protokoludur, ona görə tərcümə edən cihaz peer-lər inkapsulyasiya etməsə onu atır; UDP 4500 məhz bunu təmin edir. Özü də ev routeri və ya bulud NAT şlüzü arxasında duran Windows serverində IPsec mərhələsi AssumeUDPEncapsulationContextOnSendRule PolicyAgent açarı altında 2-yə qoyulana və maşın yenidən başladılana qədər 789 xətası ilə uğursuz olur və nasazlıq bağlı portdan fərqlənmir. NAT arxasındakı müştərilər daha asandır: serverdə ümumi ünvan olduqda UDP 4500 üzərində NAT-T onları daşıyır və o dəyər işə qarışmır.

PPP qalxdıqdan sonra qara dəlikli MTU ölü tuneli təqlid edir: kiçik paketlər keçir, TLS əl sıxışması və ya səhifə yüklənməsi donur və müştəri hələ də qoşulmuş göstərə bilər. Serveri günahlandırmazdan əvvəl interfeys MTU-nu aşağı salın və ya şlüzdə MSS-i sıxın. Split-tunel marşrutlaşdırması digər saxtakardır; səhv maska ilə göndərilən subnet tuneli sağlam, bir tətbiqi isə əlçatmaz qoyur. Şəxsi host adı öz addımını əlavə edir: sorğu yerli resolverdən çıxırsa, heç bir marşrut sınaqdan keçməmiş ad həll olunmur.

Etimad məlumatlarına toxunmazdan əvvəl yoxlama siyahısı

Siyahını ardıcıllıqla işləyin və ilk uğursuz bənddə dayanın. Hər addım ucuzdur və hər biri bütöv bir düzəliş sinfini istisna edir.

1. Assosiasiyanın hər iki tərəfdə olduğunu təsdiqləyin, qoşulma etiketi ilə deyil, peer şəxsiyyəti ilə uyğunlaşdırın.
2. UDP 1701-in xl2tpd-yə çatdığını təsdiqləyin; çağırışsız assosiasiya sizin nasazlığınızdır.
3. Şifrənin səhv olduğunu fərz etməzdən əvvəl PPP-nin hökmünü, autentifikasiya olunubsa IPCP nəticəsini oxuyun.
4. Yalnız indi etimad məlumatlarını serverin gözlədiyi formatda yenidən daxil edin, çünki domen prefiksi hesabı dəyişir.
5. Hələ də uğursuz olursa, hər iki tərəfi uyğunlaşdırılmış vaxt damğaları ilə tutun və mərhələ-mərhələ müqayisə edin.

İkinci addımda dayanmaq yol və ya inkapsulyasiya problemi deməkdir və heç bir şifrə düzəlişi onu tərpətməyəcək. Üçüncü addımda dayanmaq jurnalın artıq düzəldilməli metodu və ya ünvan hovuzunu adlandırdığını bildirir. Hər iki halda növbəti dəyişiklik əsaslandıra biləcəyiniz dəyişiklikdir və heç vaxt iştirak etməmiş parametrlər arasında fırlanmağı dayandırırsınız.