PPTP შეცდომა 800 და 812 და კავშირის გაწყვეტა ერთი წუთის შემდეგ

ერთი PPTP კლიენტის სამი შეცდომის შეტყობინება ჩვეულებრივ სამ სხვადასხვა ხარვეზს აღწერს. შეცდომა 800 ნიშნავს, რომ გვირაბი არასდროს შეიქმნა, შეცდომა 812 ნიშნავს, რომ სერვერმა უარყო ავთენტიფიკაციის მეთოდი, ხოლო ერთი წუთის შემდეგ გაწყვეტა არის keepalive ტაიმერი, რომელიც წყვეტს, რომ ჯანსაღი პარტნიორი წავიდა. ყოველი ეტაპი საკუთარი მიზეზით ჩავარდება, ამიტომ თითოეულს საკუთარი შემოწმება სჭირდება.

შეცდომა 800 ნიშნავს, რომ გვირაბი არასდროს შეიქმნა

Windows შეცდომა 800-ს აჩვენებს, როცა გვირაბის აშენება საერთოდ არ შეუძლია, ხოლო ტექსტი მიუწვდომელ სერვერზე ან შეუფერებელ უსაფრთხოების პარამეტრებზე შეჯამებაა და არა დიაგნოზი. PPTP-ს ქსელისგან ორი ცალკე რამ სჭირდება, სანამ რომელიმე სერტიფიკატი შემოწმდება. TCP 1723 ატარებს მართვის არხს, ხოლო IP პროტოკოლი 47, GRE, ატარებს ინკაფსულირებულ დატვირთვას.

შეამოწმეთ ეს გარე გზა თქვენივე LAN-ის გარედან, რადგან ოფისში მომუშავე კავშირი კიდეზე არაფერს ამტკიცებს:

$ 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 პასუხობს და ჩანაწერი ცარიელი რჩება, სანამ კლიენტი დაკავშირებას ცდილობს, გზა პროტოკოლ 47-ს ყრის. როუტერი, რომელშიც 1723 გადამისამართებულია, მაგრამ PPTP-ის გავლა გამორთულია, ზუსტად ამ სურათს იძლევა: TCP ხელის ჩამორთმევა სრულდება, შემდეგ GRE პაკეტები ქრება, ამიტომ ხარვეზი სერტიფიკატის პრობლემას ჰგავს, თუმცა შესვლის ცდა არ ყოფილა.

მიმართეთ გადამისამართება სერვერის ამჟამინდელ LAN მისამართზე, ჩართეთ PPTP-ის გავლა იქ, სადაც როუტერი გთავაზობთ, და სცადეთ ხელახლა იმავე გარე წერტილიდან. როცა GRE ზემოთ იფილტრება და ამას ვერ შეცვლით, SSTP TCP 443-ზე ან L2TP/IPsec UDP 500 და 4500-ზე უკეთესი შანსია, ვიდრე Windows-ის მხარეს თქვენეული ნებისმიერი ცვლილება.

შეცდომა 812 არის სერვერის მიერ თქვენი ავთენტიფიკაციის მეთოდის უარყოფა

შეცდომა 812 ბრუნდება მას შემდეგ, რაც გვირაბი აწეულია, ამიტომ პაროლის პრობლემად აღიქმება. სერვერი უარყოფს კავშირისთვის შეთანხმებულ ავთენტიფიკაციის მეთოდს და არა აუცილებლად თავად პაროლს. კლიენტზე გახსენით VPN ჩანაწერი, გადადით უსაფრთხოების ჩანართზე, დააყენეთ ტიპი Point-to-Point Tunneling Protocol-ზე, აირჩიეთ პროტოკოლების ცხადი სია და მონიშნეთ Microsoft CHAP ვერსია 2.

მიმდინარე პარამეტრის წაკითხვა დიალოგში დაწკაპუნების გარეშე შეგიძლიათ:

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

სერვერი, რომელიც MS-CHAP v2-ს მოითხოვს, უარყოფს კლიენტს, რომელიც PAP-ზე ან ავტომატურ ტიპზეა დატოვებული და უფრო სუსტზე თანხმდება, და შეცდომა მოდის მანამ, სანამ რომელიმე მომხმარებლის პაროლი შეფასდება. ანგარიშის ფორმატი იმავე უარყოფის მეორე ნახევარია. ერთ შემთხვევაში Windows-მა გაგზავნა MicrosoftAccount\[email protected] ფორმის Microsoft ანგარიშის იდენტობა, მაშინ როცა სერვერს ლოკალური ან დომენური ანგარიში სურდა. SERVERNAME\username-ის აკრეფამ Windows-ს უთხრა, რომელ ანგარიშთა საცავს მიმართოს, და შეცდომა მოაშორა. შეიყვანეთ სახელი ხელით, ნაცვლად იმისა, რომ შენახულ სერტიფიკატს წინა ფორმატის გამეორების უფლება მისცეთ.

ერთი წუთის შემდეგ გაწყვეტები keepalive გადაწყვეტილებაა

როცა გვირაბი უკავშირდება, ცოტა ტრაფიკს გაატარებს და შემდეგ ითიშება, კლიენტზე ხელის შეხებამდე შეხედეთ სერვერის LCP ექოს ქცევას. დემონი პერიოდულად სთხოვს პარტნიორს დაადასტუროს, რომ ჯერ კიდევ იქ არის. თუ დაყენებული ბიუჯეტის ფარგლებში ძალიან ცოტა პასუხი მოვა, სესია იშლება მაშინაც, როცა მომხმარებელს ჯერ კიდევ მუშა კავშირი აქვს.

Linux pptpd სერვერზე ეს მნიშვნელობები /etc/ppp/options.pptpd-ში ცხოვრობს, და ჩვეულებრივი შეკეთება ბიუჯეტის გაფართოებაა და არა ინტერვალის შემოკლება:

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

ოცდაათი გამოტოვება ხუთწამიან ინტერვალზე პატიობს ხანმოკლე შეჩერებას, ნაცვლად იმისა, რომ პარტნიორი წასული გამოაცხადოს. რიცხვის ერთ ან ორამდე დაწევა გადათარგმნილ გზაზე ჩვეულ რხევას დაახლოებით ყოველ წუთში გათიშვად აქცევს. თუ თქვენი სერვერი pptpd-ის ნაცვლად Windows RRAS-ია, ნაცვლად ამისა შეხედეთ PPP სესიის დროის ლიმიტს და უმოქმედობისას გათიშვის პოლიტიკას. ისინი სხვაგან ცხოვრობენ, და არარსებული pppd ფაილის რედაქტირება არაფერს შეცვლის.

გადამფარავი ქვექსელები ამტვრევს მონაცემთა გზას

PPTP გვირაბს შეუძლია სუფთად ავთენტიფიკაცია და მაინც ვერაფერს მიაღწიოს, როცა ორივე ადგილი ერთსა და იმავე კერძო დიაპაზონს იყენებს, მაგალითად 192.168.1.0/24 ოფისში და სახლში. კლიენტს არ შეუძლია თქვას, რომელ ჰოსტს გულისხმობს მოცემული მისამართი, და ზოგიერთი სტეკი საერთოდ უარყოფს მარშრუტის დაყენებას, ნაცვლად ერთის არჩევისა.

მოეპყარით ამას როგორც დიზაინის ხარვეზს და გადანომრეთ ერთი მხარე, ან მიეცით კლიენტს განზრახ თარგმნილი წვდომის დიაპაზონი. PPTP კლიენტის გამართვა ვერ გაასწორებს ორჯერ არსებულ მისამართთა სივრცეს, და სიმპტომი გაგრძელდება შემთხვევითი გაწყვეტის მსგავსად.

დაიწყეთ იმ ეტაპით, რომელიც ჩავარდა: GRE 800-ისთვის, მეთოდი და ანგარიშის სტრიქონი 812-ისთვის, ექოს პარამეტრები გრაფიკით მკვდარი გვირაბისთვის.