PPTP-ის გამტარობა აკლია: Windows VPN შეცდომა 807-ის გასწორება

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

პორტების ცხრილს პროტოკოლის ნომრისთვის სტრიქონი არ აქვს

PPTP იყენებს ორ საუბარს, რომლებიც სხვადასხვაგვარად ფუჭდება. TCP 1723-ზე მყოფი იწყებს ზარს, გადასცემს კავშირის ინფორმაციას და წყვეტს მას, როცა მომხმარებელი გამოეთიშება. დატვირთვის მხარე მუშაობს GRE-ის შიგნით, რომელსაც IP სათაური აღნიშნავს 47 პროტოკოლის ნომრით, და იმ გვირაბის შიგნით PPP აწარმოებს მოლაპარაკებას კავშირზე, ხოლო MS-CHAPv2 ამოწმებს მონაცემებს.

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

რას აცნობს Windows, როცა მონაცემთა გზა კვდება

807 შეცდომა ამბობს, რომ კავშირი ვერ დასრულდა, რაც პრაქტიკაში ნიშნავს, რომ ზარი მიაღწია სერვერს და მონაცემთა არხი არ ადგა. ეს ტრანსპორტის შესახებ განაჩენია და არა ანგარიშის. 691 შეცდომაა ის, რომელიც მიუთითებს იდენტიფიკაციის მონაცემებზე ან ავთენტიფიკაციის პროტოკოლის შეუსაბამობაზე, ამიტომ გაგზავნის სრულიად სხვა ადგილას.

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

რატომ ამტვრევს მეორე კლიენტი მუშა გვირაბს

რადგან პორტები არ არსებობს მათ გასარჩევად, NAT მოწყობილობა ვერ გამოყოფს ორ PPTP კლიენტს ისე, როგორც ყოფს ორ HTTPS სესიას. ამიტომ ბევრი სამომხმარებლო მოწყობილობა უშვებს ერთ PPTP ზარს და თვალს ადევნებს მას წყაროს მისამართით. ნოუთბუქი, რომელიც მარტო მუშაობდა, წყვეტს დასრულებას, როგორც კი მეორე მანქანა აკრავს ნომერს, და კლიენტის მხრიდან ჩავარდნა შემთხვევით გამოიყურება. ეს ნიმუში პროგრამულ უზრუნველყოფას ეკუთვნის და ვერც ერთი პროფილის ცვლილება შეცვლის მას.

დააკვირდით კავშირების ცხრილს, სანამ ორივე კლიენტი აკრავს ნომერს. თუ მუდამ მხოლოდ პირველი ჰოსტი ინახავს ასახვას, მარშრუტიზატორმა მიაღწია თავისი მხარდაჭერის ზღვარს და კლიენტის ვერც ერთი პარამეტრი ვერ გადაადგილებს მას.

დაამტკიცეთ, რომელი ნახევარი ფუჭდება

დაადასტურეთ, რომ TCP 1723 აღწევს, სანამ მარშრუტიზატორზე რაიმეს შეცვლით, რადგან ეს პასუხი წყვეტს, რომელ ნახევარს ამოწმებთ. გაუშვით ესენი Windows კლიენტიდან საკუთარი სერვერის სახელის წინააღმდეგ. პირველი ბეჭდავს, უპასუხა თუ არა პორტმა, ხოლო მეორე აკრავს ნომერს დიალოგის გარეშე, რაც განმეორებით მცდელობებს შედარებადს ხდის.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

პორტის ტესტში ჭეშმარიტი შედეგი ნიშნავს, რომ მართვის არხი ღიაა და GRE დარჩენილი ეჭვმიტანილია. ყალბი შედეგი ნიშნავს, რომ მარშრუტიზაცია, ფილტრი ან გადაგზავნა გატეხილია და GRE-ის ვერც ერთი ცვლილება ვერ იხსნის მას. მონაცემთა მხარეს უნდა დავაკვირდეთ იქ, სადაც ის ჩანს, სერვერზე ან მარშრუტიზატორზე.

tcpdump -ni any proto 47

Wireshark-ში ეკვივალენტია ჩვენების ფილტრი ip proto 47, რომლის გადაცემაც უფრო იოლია იმისთვის, ვისაც ბრძანების სტრიქონში კომფორტულად არ გრძნობს თავს. GRE, რომელიც მოდის ისე, რომ პასუხში არაფერი გადის, ნიშნავს, რომ დაბრუნების გზა უნდა გასწორდეს.

რა ასწორებს შეცდომას სინამდვილეში

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP-ის შეცვლა მეორე ვარიანტია და ხშირად უფრო იაფი. მარშრუტიზატორი, რომელიც თავად ამთავრებს VPN-ს, თავს არიდებს ორმაგ NAT-ს შემომავალი კლიენტებისთვის, და პროტოკოლს, რომელსაც პორტზე დაფუძნებული NAT უკვე ამუშავებს, გამტარობა საერთოდ არ სჭირდება: OpenVPN UDP-ზე, SSTP TCP 443-ზე ან L2TP/IPsec NAT-T-ით, რომელიც ESP-ს UDP 4500-ში ახვევს. PPTP ასევე დამოკიდებულია MS-CHAPv2-ზე, რომლის დოკუმენტირებული სისუსტეები მას ცუდ არჩევანად აქცევს ახალი განლაგებისთვის შეცდომის გაქრობის შემდეგაც.

ჩაწერეთ, რომელმა წესმა შექმნა განსხვავება, რადგან იმავე საიტს იგივე ზღვარი შეხვდება, როცა მეორე მომხმარებელი მოითხოვს წვდომას. პროტოკოლის დონის გასწორება ქსელის ჩანაწერებშია მოსათავსებელი, სადაც შემდეგი ინჟინერი შეხედავს.