PPTP სერვერი სახლის როუტერის უკან: ჯერ 1723 და GRE გაასწორეთ
გაუშვით PPTP სახლის როუტერის უკან: TCP 1723, IP პროტოკოლი 47, გავლის უჯრა და MTU-ის არითმეტიკა, და როდის არის L2TP ან OpenVPN უკეთესი გაცვლა.
PPTP სახლის როუტერის უკან ორი დაუკავშირებელი გზით ვარდება და მათი არევა მთელ საღამოს ხარჯავს. ერთი ხარვეზი გადაგზავნის ხვრელია: როუტერი TCP 1723-ს გაატარებს და IP პროტოკოლ 47-ს ყრის, ამიტომ კლიენტი 619 შეცდომაზე ჩერდება. მეორე ზომის პრობლემაა: გვირაბი ადის, ავთენტიფიკაციას გადის და შემდეგ იყინება, როცა სრული ზომის პაკეტმა უნდა გაიაროს. იმის გარკვევა, რომელი გაქვთ, პირველი ნამდვილი ნაბიჯია; დანარჩენი ადარებს, რისი გამოხატვა შეუძლია თქვენს როუტერს და არა რომელი ბრენდია უკეთესი.
ორი ტრანსპორტი, და მხოლოდ ერთს აქვს პორტი
PPTP ორ ტრანსპორტად იყოფა: საკონტროლო კავშირი TCP 1723-ზე და PPP კადრები გაფართოებულ GRE-ში გახვეული, რაც IP პროტოკოლი 47-ია. GRE-ს პორტის ნომერი არ აქვს, ამიტომ 1723 პორტის გადაგზავნად დაწერილი წესი ვერ დაფარავს მას, როგორც არ უნდა დაარქვას ვებ ინტერფეისმა ველს. სახლის როუტერი ჩვეულებრივ პროტოკოლის წესის ნაცვლად გთავაზობთ PPTP გავლის სახელის უჯრას, და ეს უჯრა ორ საქმეს აკეთებს: 47 პროტოკოლს ცეცხლოვან კედელში ატარებს და NAT-ს ასწავლის GRE ნაკადის თვალყურის დევნებას. Linux როუტერზე ეს საქმეები ცალკე მოდულები და ცალკე წესებია, ამიტომ ნახევრად კონფიგურირებული გავლა მაინც მუშა საკონტროლო არხს იძლევა. გაარკვიეთ, რომელი ნახევარია აქ, სანამ რამეს შეცვლით.
სერვერის საკუთარი ცეცხლოვანი კედელიც უნდა უშვებდეს 47 პროტოკოლს როუტერის მისამართიდან. ჰოსტის ცეცხლოვანი კედელი, რომელიც მხოლოდ 1723/tcp-ს იღებს, 619 შეცდომას LAN-ის შიგნიდან იმეორებს, რაც გატეხილ გადაგზავნას და გატეხილ ჰოსტის წესს ერთნაირს ხდის.
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'თუ მოდულები არ არის, ჩატვირთეთ ისინი sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre-ით და ჩატვირთვა მუდმივი გახადეთ, რადგან დამხმარის დავიწყებული გადატვირთვა მუშა გვირაბს ისევ 619 შეცდომად აქცევს. გადაგზავნის წესმა 47 პროტოკოლი მხოლოდ სერვერის მისამართის მიმართულებით უნდა მიიღოს, და არა მთელი LAN. RFC 2637-ის განმარტება საკონტროლო და მონაცემთა ბილიკებს ჰყოფს, ამიტომ არც ერთი პორტის გადაგზავნის ეკრანი PPTP-ს სრულად არ აღწერს.
გავლის უჯრა თუ პროტოკოლის ცხადი წესი
გავლის უჯრა, რომელიც მხოლოდ ცეცხლოვან კედელს ხსნის, უფრო ახლოსაა სწორთან, ვიდრე ALG, რომელიც ზარის იდენტიფიკატორებს გადაწერს. ცეცხლოვანი კედლის ნახევარი პროგნოზირებადია, რადგან 47 პროტოკოლი ან მიიღება, ან ყრიან, და მთვლელები ამბობენ რომელი. გადაწერის ნახევარი ის ადგილია, სადაც მწარმოებლები განსხვავდებიან, რადგან PPTP-ის ზარის იდენტიფიკატორები თითოეულ გვირაბზეა და მათი რედაქტირების NAT-მა ყოველ შეხებულ ზარს უნდა მიჰყვეს. როცა ერთი კლიენტი უკავშირდება და ორი არა, ALG პირველი ეჭვმიტანილია.
1723-ის დანიშნულების NAT წესს მესაკუთრის პრობლემაც აქვს. თუ ძველი წესი ჯერ კიდევ 1723-ს უგზავნის ჰოსტს, რომელმაც სერვერი შეწყვიტა, პაკეტები დახურულ პორტზე ეცემა და როუტერის საკუთარი PPTP სერვისი პასუხს წყვეტს, რაც ცეცხლოვანი კედლის ხარვეზად იკითხება, მაგრამ სინამდვილეში მოძველებული სამიზნეა. წესი და მისი დანიშნულება წაიკითხეთ, სანამ მეორეს დაუმატებთ. როუტერებზე, რომლებიც თავად ამთავრებენ PPTP-ს, WAN წესი ჩაშენებულ სერვისს ეჯიბრება, ამიტომ 1723-ისა და 47 პროტოკოლისთვის ერთი მესაკუთრე აირჩიეთ.
ერთი NAT-ის უკან ორი კლიენტი ის შემთხვევაა, რომელიც მარტივ გადაგზავნას ჭკვიანისგან ჰყოფს. 47 პროტოკოლის გადაგზავნა ზარის იდენტიფიკატორების გადაწერის გარეშე ჩვეულებრივ უკეთ იქცევა, ვიდრე დამხმარე, რომელიც მათ გასწორებას ცდილობს.
გაზომეთ გვირაბი, სანამ როუტერს დაადანაშაულებთ
PPTP სასარგებლო დატვირთვას ამცირებს, და ეს შემცირება არითმეტიკაა და არა საიდუმლო. გვირაბის ყოველი პაკეტი ატარებს გარე IP სათაურს, გაფართოებულ GRE სათაურს, PPP სათაურს და დაშიფვრისას MPPE სათაურს. როცა ბილიკი ვერ ატარებს წარმოქმნილ კადრს, მცირე პაკეტები გადის, შესვლა სრულდება და სესია ჩერდება პირველად მაშინ, როცა ფაილის გადაცემა ან TLS ხელის ჩამორთმევა სრული ზომის პაკეტს აგზავნის.
გამოთვალეთ რიცხვი და ნუ გამოიცნობთ. გაფართოებული GRE 8 ბაიტია, PPP 4, MPPE 4, გარე IP სათაური 20, ამიტომ გვირაბი ნებისმიერ დატვირთვამდე 36 ბაიტს ჭამს. PPPoE WAN-ზე, რომელიც 1492-ზე მთავრდება, ყველაზე დიდი მოთავსებადი PPP MTU არის 1492 გამოკლებული 36, ანუ 1456. PPP პარამეტრებში mtu და mru ამ მნიშვნელობაზე დააყენეთ და ხელახლა გამოსცადეთ დაყოფის გარეშე ping-ით.
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpdping ბილიკს ზომავს და არა გვირაბს: 1464 ბაიტი დატვირთვა პლუს 28 ბაიტი IP და ICMP სათაური ზუსტად ავსებს 1492 ბაიტის კადრს. თუ ეს ping ვერ გაიარა, რიცხვი შეამცირეთ სანამ არ გაივლის, შემდეგ შედეგს 36 გამოაკელით. ბილიკის ზღვარზე მაღლა დაყენებული გვირაბის MTU ყინვას ქმნის ზომის ხსენების გარეშე, არც ერთი ჟურნალის ხაზის გარეშე.
PPTP, L2TP/IPsec ან OpenVPN ერთსა და იმავე როუტერზე
იგივე როუტერს შეუძლია სამი ჩვეულებრივი გვირაბიდან ნებისმიერი ატაროს, და განსხვავება ისაა, რა უნდა გამოხატოს. PPTP ორ წესს ორ სხვადასხვა შრეში მოითხოვს. IPsec-ზე L2TP-ს გასაღების გაცვლისთვის UDP 500 და 4500 სჭირდება, და თუ NAT-T არ ატარებს, დატვირთვისთვის 50 პროტოკოლი. OpenVPN-ს ერთი UDP პორტი სჭირდება და საერთოდ არანაირი დამხმარე.
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
L2TP-ის სვეტი ავტომატურად არ არის GRE-ზე მეგობრული. ESP არის IP პროტოკოლი 50 და მასაც არ აქვს პორტი, ამიტომ როუტერს, რომელსაც 47 პროტოკოლთან უჭირს, იმავე მიზეზით 50 პროტოკოლთანაც შეიძლება გაუჭირდეს. NAT-T არსებობს იმისთვის, რომ ESP UDP 4500-ში ჩაიხვიოს, და როცა ორივე ბოლო მას მხარს უჭერს, 50 პროტოკოლის წესი ზედმეტი ხდება. ეს ბოლოების თვისებაა და არა როუტერის PPTP უჯრის. სანამ ორივესთვის წესებს დაწერთ, დაადასტურეთ, რომელ ინკაფსულაციაზე შეთანხმდა სინამდვილეში კლიენტი.
OpenVPN არის ვარიანტი ყველაზე ნაკლები მოძრავი ნაწილით როუტერის მხარეს. ერთი UDP პორტი, ერთი გადაგზავნა, არანაირი კავშირების თვალყურის დევნების დამხმარე და ზარის იდენტიფიკატორების გადაწერა არ ხდება. გაცვლა არის კლიენტი, რომელიც უნდა ჩაინსტალირდეს ჩაშენებული ამომრჩევის ნაცვლად, და ხშირად ეს არის ერთადერთი მიზეზი, რის გამოც PPTP საუბარში რჩება.
რა შევაკეთოთ და რა შევცვალოთ
გადაგზავნისა და MTU-ის გასწორება მოგცემთ მუშა გვირაბს და არა ისეთს, რომელიც უნდა შეინარჩუნოთ. PPTP-ის MSCHAPv2 ავთენტიფიკაცია წლებია თავდასხმადია, და მუშა გვირაბი გადაადგილებს მონაცემებს, რომელთა აღდგენაც ოფლაინ შეიძლება. თუ დისტანციურ მოწყობილობას შეუძლია L2TP/IPsec ან OpenVPN, შეკეთება თარიღიან დროებით ზომად მიიჩნიეთ.
გადაწყვეტილება დამოკიდებულია იმაზე, რასაც შორეული ბოლო უჭერს მხარს და რამდენ ხანს უნდა გაგრძელდეს წესრიგი. მოწყობილობა, რომელიც მხოლოდ PPTP-ს ლაპარაკობს, შეკეთებას იღებს; ყველაფერი, სადაც კლიენტის დაყენება შეიძლება, მიგრირდება.
სანამ ბილეთს დახურავთ, დაადასტურეთ, რომ კლიენტი დიდ გადაცემას უძლებს და არა მხოლოდ შესვლას, და რომ როუტერი გადატვირთვის შემდეგაც ინახავს 47 პროტოკოლის წესს. გვირაბი, რომელიც ერთ ფაილის კოპირებას გადის და შემდეგი firmware განახლების შემდეგ იღუპება, არასდროს ყოფილა დასრულებული.