PPTP xətası 800 və 812, bir dəqiqədən sonra qopan bağlantılar

Bir PPTP müştərisindən gələn üç xəta mesajı adətən üç fərqli nasazlığı təsvir edir. 800 xətası tunelin heç vaxt qurulmadığını, 812 xətası serverin autentifikasiya metodunu rədd etdiyini bildirir, bir dəqiqədən sonra qopan bağlantı isə sağlam həmyaşıdın getdiyinə qərar verən canlılıq taymeridir. Hər mərhələ öz səbəbindən uğursuz olur, ona görə də hər birinə öz yoxlaması lazımdır.

800 xətası tunelin heç vaxt qurulmadığını bildirir

Windows 800 xətasını tuneli ümumiyyətlə qura bilmədikdə qaldırır və əlçatmaz server və ya uyğun olmayan təhlükəsizlik parametrləri barədə mətn diaqnoz deyil, xülasədir. PPTP hər hansı etimad məlumatı yoxlanmazdan əvvəl şəbəkədən iki ayrı şey tələb edir. TCP 1723 idarəetmə kanalını, IP protokolu 47, yəni GRE, isə inkapsulyasiya edilmiş yükü daşıyır.

Bu xarici yolu öz LAN-ınızdan kənarda sınayın, çünki ofisin içində işləyən bağlantı kənar haqqında heç nə sübut etmir:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

1723 cavab verirsə və müştəri qoşulmağa çalışarkən ələ keçirmə boş qalırsa, yol 47 protokolunu atır. 1723-ü yönləndirən, lakin PPTP keçidi söndürülmüş marşrutlaşdırıcı məhz belə bir mənzərə yaradır: TCP əl sıxışması tamamlanır, sonra GRE paketləri yox olur, buna görə nasazlıq etimad məlumatı problemi kimi görünür, halbuki heç bir giriş cəhdi edilməyib.

Yönləndirməni serverin cari LAN ünvanına yönəldin, marşrutlaşdırıcı təklif edirsə PPTP keçidini aktivləşdirin və eyni xarici nöqtədən yenidən cəhd edin. GRE yuxarı axında filtrlənirsə və bunu dəyişə bilmirsinizsə, TCP 443 üzərində SSTP və ya UDP 500 və 4500 üzərində L2TP/IPsec, Windows tərəfində edə biləcəyiniz hər hansı dəyişiklikdən daha yaxşı şansa malikdir.

812 xətası serverin autentifikasiya metodunuzu rədd etməsidir

812 xətası tunel qurulduqdan sonra qayıdır, buna görə şifrə problemi kimi hiss olunur. Server bağlantı üçün razılaşdırılmış autentifikasiya metodunu rədd edir, mütləq şifrənin özünü deyil. Müştəridə VPN girişini açın, Təhlükəsizlik sekmesine keçin, növü Point-to-Point Tunneling Protocol olaraq təyin edin, açıq protokol siyahısını seçin və Microsoft CHAP Versiya 2-ni işarələyin.

Cari parametri dialoqda gəzmədən oxuya bilərsiniz:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 tələb edən server PAP-da və ya daha zəif bir şey üzərində razılaşan avtomatik növdə qalmış müştərini rədd edir və xəta istənilən istifadəçi şifrəsi qiymətləndirilməzdən əvvəl gəlir. Hesab formatı eyni rəddin digər yarısıdır. Bir halda Windows MicrosoftAccount\[email protected] formasında Microsoft hesabı kimliyi göndərdi, halbuki server yerli və ya domen hesabı istəyirdi. SERVERNAME\username yazmaq Windows-a hansı hesab anbarına müraciət etməli olduğunu bildirdi və xətanı aradan qaldırdı. Adı yadda saxlanmış etimad məlumatının əvvəlki formatı təkrarlamasına imkan verməkdənsə, əl ilə daxil edin.

Bir dəqiqədən sonra qopmalar canlılıq qərarıdır

Tunel qoşulur, bir az trafik keçirir və sonra ayrılırsa, müştəriyə toxunmazdan əvvəl serverin LCP echo davranışına baxın. Demon vaxtaşırı həmyaşıddan hələ də orada olduğunu təsdiqləməsini xahiş edir. Müəyyən edilmiş büdcə daxilində çox az cavab gəlirsə, istifadəçinin hələ də işlək əlaqəsi olsa da, sessiya ləğv edilir.

Linux pptpd serverində bu dəyərlər /etc/ppp/options.pptpd faylında yaşayır və adi düzəliş intervalı qısaltmaq deyil, büdcəni genişlətməkdir:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Beş saniyəlik intervalda otuz buraxılmış cavab, həmyaşıdın getdiyini elan etməkdənsə qısa bir dayanmanı bağışlayır. Sayı bir və ya ikiyə endirmək, tərcümə edilmiş yolda adi titrəməni təxminən hər dəqiqə bir ayrılmaya çevirir. Serveriniz pptpd əvəzinə Windows RRAS-dırsa, bunun əvəzinə PPP sessiya taym-autuna və boşdayanma zamanı ayrılma siyasətinə baxın. Onlar başqa yerdə yaşayır və mövcud olmayan pppd faylını redaktə etmək heç nəyi dəyişməyəcək.

Üst-üstə düşən alt şəbəkələr məlumat yolunu pozur

PPTP tuneli təmiz autentifikasiya edə və yenə də heç nəyə çata bilməz, çünki hər iki sahə eyni özəl diapazondan istifadə edir, məsələn ofisdə və evdə 192.168.1.0/24. Müştəri verilmiş ünvanın hansı hosta aid olduğunu deyə bilmir və bəzi yığmalar birini seçməkdənsə marşrutu ümumiyyətlə quraşdırmaqdan imtina edir.

Bunu dizayn qüsuru kimi qəbul edin və bir tərəfi yenidən nömrələyin və ya müştəriyə qəsdən tərcümə edilmiş giriş diapazonu verin. PPTP müştərisini sazlamaq iki dəfə mövcud olan ünvan məkanını düzəldə bilməz və simptom təsadüfi qopma kimi görünməyə davam edəcək.

Uğursuz olan mərhələdən başlayın: 800 üçün GRE, 812 üçün metod və hesab sətri, cədvəl üzrə ölən tunel üçün echo parametrləri.