PPTP უკავშირდება და შემდეგ იკიდება Linux NAT-ის უკან: GRE დამხმარე

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

გადაგზავნა არასოდეს ყოფილა პრობლემა

პორტის გადაგზავნის წესი აღწერს TCP ან UDP ტრაფიკს. მას არ შეუძლია აღწეროს დატვირთვა, რომელიც სესიის შუაში გადადის სხვა IP პროტოკოლზე, და PPTP ზუსტად ამას აკეთებს.

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

TCP კონტროლისთვის, GRE მონაცემებისთვის

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

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

შიშველი GRE PPTP-ის გარეშე ასეთ გადაწერას არ საჭიროებს, ამიტომ ჩვეულებრივ GRE გვირაბს შეუძლია გაიაროს იმ მარშრუტიზატორში, რომელიც იმავე გზაზე PPTP კლიენტისთვის ვარდება.

ოთხი მოდული და sysctl, რომელმაც ისინი გამორთო

ორი მოდული ამუშავებს ჩარჩოებას, nf_conntrack_proto_gre და nf_nat_proto_gre. კიდევ ორი ამუშავებს ზარის იდენტიფიკატორს, nf_conntrack_pptp და nf_nat_pptp. უკანასკნელის ჩატვირთვა დანარჩენებს დამოკიდებულებებით მოიზიდავს, ამიტომ მოდულების სიამ ოთხივე უნდა აჩვენოს.

ძველი ინსტრუქციები იყენებენ 2.6 ეპოქის ip_ პრეფიქსს. ეს ბრძანებები შეიძლება ისე გამოიყურებოდეს, თითქოს მუშაობენ, სინამდვილეში კი არაფერს ტვირთავენ, ამიტომ შეამოწმეთ ჩატვირთული სია და არა გასვლის სტატუსი.

მათი ჩატვირთული ყოფნა აღარ არის საკმარისი. Linux 4.7-დან net.netfilter.nf_conntrack_helper sysctl ნაგულისხმევად 0-ია, რაც გამორთავს დამხმარის ავტომატურ მინიჭებას ახალი ნაკადებისთვის. მარშრუტიზატორს შეიძლება ჰქონდეს ყველა მოდული და მაინც არაფერი გადათარგმნოს. შეამოწმეთ ეფექტური მნიშვნელობა, სანამ კვლავ მოდულების სიას შეხედავთ.

ან გლობალურად ხელახლა ჩართეთ ავტომატური მინიჭება, ან მიამაგრეთ დამხმარე იმ ნაკადებს, რომლებსაც ის სჭირდებათ, და დანარჩენი მშვიდად დატოვეთ:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

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

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

Firewall-ის წესი, რომელიც უშვებს 1723-ს, არაფერს ამბობს 47 პროტოკოლზე. firewalld-ში დაუშვით პროტოკოლი კლიენტისკენ მიმართულ ზონაში. ჩვეულებრივ iptables-ში მიიღეთ gre პროტოკოლი შემავალ ჯაჭვში.

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

დაკავშირების შემდეგ, ზომის ზღვარი

GRE ამატებს სათაურს, და მის შიგნით PPP კიდევ მეტს ამატებს, ამიტომ მომუშავე ბმული აცხადებს MTU-ს 1500-ზე საგრძნობლად დაბლა. პატარა პასუხები იტვირთება, დიდები კი იკიდება, რაც მეორე, შეუკავშირებელ პრობლემას ჰგავს, რომელიც ჩნდება პირველის გადაჭრის მომენტში.

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

გზის შეკეთება ამუშავებს მომხმარებელს და PPTP-ს კარგ არჩევნად არ აქცევს. MS-CHAPv2 და RC4 დიდი ხანია მოძველებულია, ამიტომ მოდულების ჩატვირთვას მოეკიდეთ როგორც დროებით შესწორებას და დაგეგმეთ გადასვლა შენარჩუნებულ პროტოკოლზე.