PPTP-ის გაყოფილი გვირაბი არ მუშაობს: ჯერ GRE გზა გაასწორეთ

უყურეთ, როგორ ადის PPTP კავშირი და ადვილია დაიჯეროთ, რომ რთული ნაწილი დასრულდა: კლიენტი ავთენტიფიცირდება, ჩნდება ppp0 ადაპტერი ან WAN Miniport და სტატუსის ფანჯარა მწვანე ხდება. შემდეგ შიდა ჰოსტზე პირველი მოთხოვნა დროის ლიმიტს გადააჭარბებს და პროფილს ადანაშაულებენ. პრაქტიკაში ორი დამოუკიდებელი შრე უნდა გაიწმინდოს: გარე ტრანსპორტი, რომელიც TCP 1723-ს და GRE-ს ატარებს, და შიდა პოლიტიკა, რომელიც განსაზღვრავს, რომელი დანიშნულებები იყენებს PPP ინტერფეისს. მწვანე სტატუსი მხოლოდ იმას ამტკიცებს, რომ პირველი შრე შეთანხმდა; მეორეზე ის არაფერს ამბობს.

მიჰყევით კლიენტს პროფილიდან კონტროლის სოკეტამდე

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

დაადასტურეთ კონტროლის კავშირი ქსელში, სანამ რომელიმე მარშრუტს შეეხებით. კლიენტზე ან სარკის პორტზე დაიჭირეთ TCP 1723 ერთი კავშირის მცდელობისთვის:

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE მეორე პროტოკოლია, არა პორტი

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

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

sudo tcpdump -ni any 'proto gre' -c 20

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

დაამტკიცეთ, რომ გვირაბი ერთ პაკეტს გადაადგილებს

როგორც კი GRE მოედინება, PPP მოლაპარაკება კლიენტის ინტერფეისს მისამართს ანიჭებს. წაიკითხეთ მინიჭება, ვიდრე ჩათვალოთ:

ip -4 addr show ppp0

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

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

დაწერეთ გაყოფილი პოლიტიკა, DNS-ის ჩათვლით

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

შეამოწმეთ გადაწყვეტილება, რომელსაც ბირთვი იღებს თითო მისამართზე თითოეულ კატეგორიაში:

ip route get 10.20.5.10
ip route get 203.0.113.25

პირველმა უნდა დაასახელოს ppp0, მეორემ ჩვეულებრივი კარიბჭე. თუ ორივე ერთსა და იმავე ინტერფეისს ასახელებს, პოლიტიკა საერთოდ არ არის გაყოფილი. დაამატეთ DNS სერვერის საკუთარი მისამართი გვირაბის სიაში, თორემ შიდა ჰოსტების სახელების გადაწყვეტა ლოკალური გადამწყვეტით გადის და სასარგებლოს არაფერს აბრუნებს.

განმეორებადი შემოწმება ხუთ ნაბიჯში

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

Linux კლიენტისთვის კომპაქტური ვერსია ასე გამოიყურება:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows-ში იგივე თანმიმდევრობა მოქმედებს route print-ით და კლიენტში ნაჩვენები ადაპტერის სტატუსით. PPTP მოძველებული პროტოკოლია, და თუ სერვერი გთავაზობთ SSTP-ს ან IKEv2-ს, გადასვლა ჩვეულებრივ დროის უკეთ გამოყენებაა, ვიდრე გზის მორგება, რომელიც დამოკიდებულია 47 პროტოკოლის ყოველ ნახტომზე გავლაზე. შეამოწმეთ შემცვლელის სერტიფიკატი და ავთენტიფიკაციის ხელშეკრულება, ნაცვლად ძველი პროფილის ახალ გამოშვებაში კოპირებისა.