L2TP qoşulur, lakin PPP danışıqları alınmır: hansı mərhələ?

IPsec tuneli qurulur, müştəri qorunan peer göstərir, sonra isə heç nə şəxsi alt şəbəkəyə çatmadan bağlantı qopur. Bu boşluq PPP-nin öz işini görməsidir: keçid seçimləri, istifadəçi autentifikasiyası və ünvan təyini şifrələnmiş tunel mövcud olduqdan sonra baş verir. Uğurlu birinci mərhələ mübadiləsi heç bir parol və ya daxili ünvan vermir. Mərhələləri sıra ilə oxuyun və nasazlıq adətən özünü adlandırır.

Tunel yalnız birinci qatdır

L2TP PPP kadrlarını IPsec ilə qorunan tunelin içində daşıyır, yəni paket marşrutlaşdırılmadan əvvəl iki müstəqil danışıq uğurla başa çatmalıdır. Xarici danışıq hər iki tərəfin açarlar və kimliklər barədə razılaşdığını sübut edir. Daxili danışıq keçid parametrlərini, istifadəçinin autentifikasiya olunub-olunmadığını və müştərinin hansı ünvanı alacağını müəyyən edir.

PPP daxilindəki nasazlıq hər müştəridə tək status işığı göstərən pozulmuş tunel kimi görünür. Onu tunel problemi kimi qəbul etmək açarların yenilənməsinə, xidmətlərin yenidən başladılmasına və nəhayət heç vaxt səhv olmamış ortaq sirrin dəyişdirilməsinə gətirib çıxarır. Faydalı fərq ucuzdur: əgər peer mübadiləsi tamamlanıbsa və müştəri istifadəçi adı sorğusuna və ya autentifikasiya mərhələsinə keçibsə, tunel qaydasındadır. Bundan sonrakı hər şey PPP-yə aiddir.

Uğurlu olan son mərhələni oxuyun

Jurnalı irəliyə doğru oxuyun və tamamlanmayan ilk mərhələdə dayanın. Əvvəlcə LCP, sonra autentifikasiya, sonra IPv4 parametrləri üçün IPCP gəlir.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP fasiləsi iki tərəfin əsas keçid seçimləri barədə heç vaxt razılaşmadığını bildirir ki, bu da pis parol deyil, profil uyğunsuzluğu və ya bloklanmış daxili protokoldur. Açıq autentifikasiya imtinası əks haldır: keçid qalxdı və bir tərəf etimadnamələri rədd etdi. Uğurlu autentifikasiyadan sonra IPCP fasiləsi ünvan hovuzlarına və ya server siyasətinə işarə edir. Bunların hər birinin fərqli sahibi və fərqli təmiri var, buna görə mərhələ son xəta mətnindən daha vacibdir.

Jurnal çıxarışını biletin içində mərhələ adı ilə birlikdə saxlayın. Mərhələ sərhədi olmadan yapışdırılmış quyruq növbəti oxucunu təxmin etməyə dəvət edir və burada təxmin etmək bir saat baha başa gəlir.

Müştəri ilə server arasında razılıq

Hər iki tərəf eyni autentifikasiya metodunu qəbul etməlidir və saxlanmış profil serverin keçən rübdə ləğv etdiyi metodu tələb edə bilər. İdarə olunan yerləşdirmələr server tərəfini də gizlədir; orada imtina səbəbi adətən cihaza deyil, istifadəçiyə yazılır.

Hər köhnə seçim yerinə bir dəstəklənən metod aktivləşdirin, çünki beş metod təklif edən müştəri hansının uğursuz olduğunu örtür. Administratora server tərəfinin siyasətini və dəqiq imtinanı soruşun; bu, heç kimin parol dərc etməsini tələb etmir. Bir müştərini xilas etmək üçün aktivləşdirilən köhnə metod faylı kopyalayan hər profilə yayılmağa meyllidir.

Ünvanı yoxlayın, girişi yox

Tamamlanmış giriş istifadə oluna bilən sessiya deyil. IPCP daxili ünvanı razılaşdırır və tükənmiş hovuz və ya müştərini rədd edən siyasət yenə də marşrutlaşdırılacaq heç nəsi olmayan qoşulmuş tunel buraxa bilər.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Əvvəlcə daxili ünvanı, sonra həqiqətən ehtiyac duyduğunuz resurs üçün marşrutu və həlledicini yoxlayın. Daxili ünvan veb saytın bildirdiyi ictimai çıxış deyil və ikisini qarışdırmaq insanları olmayan sızmanın axtarışına göndərir. Şəxsi resursu adla yoxlamadan əvvəl ünvanla yoxlayın ki, DNS nasazlığı marşrutlaşdırma nasazlığı ilə səhv salınmasın.

Mərhələni, metodu və ünvanı bir qeydə yazın və tarix qoyun. Eyni hesab bir ay sonra yenidən uğursuz olarsa, həmin qeyd beş dəqiqəlik yoxlama ilə yeni araşdırma arasındakı fərqdir. Fərqli mərhələlərdəki nasazlıqlar, müştəri tək dialoq göstərsə belə, fərqli hadisələrdir.