PPTP Docker-ში ავთენტიფიკაციას გადის, მაგრამ ტრაფიკს არ გადააქვს

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

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

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

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

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

შემოწმება 2: დაადასტურეთ დამხმარე ჰოსტის ბირთვში

კავშირების თვალთვალი ვერ დააკავშირებს TCP კონტროლის კავშირს GRE ნაკადთან დამხმარის გარეშე. მოდული nf_conntrack_pptp-ია, ის ჰოსტის ბირთვში ცხოვრობს, და კონტეინერის იმიჯში მისი ჩატვირთვა არაფერს იძლევა, რადგან მოდულები მთელ ჰოსტზე მოქმედებს. lsmod | grep nf_conntrack_pptp Docker-ის ჰოსტზე სწორედ შემოწმებაა. თუ ის არ არის, modprobe nf_conntrack_pptp მას მიმდინარე ბირთვისთვის ტვირთავს და მომდევნო ჩატვირთვაზე არაფერს ამბობს, ამიტომ დაამატეთ ის ჰოსტის კონფიგურაციაშიც.

მოდული, რომელიც გადატვირთვისას ქრება, მომავალ თვეში იგივე ბილეთი ხდება.

შემოწმება 3: წაიკითხეთ ბირთვის პოლიტიკა, რომელიც მას თიშავს

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

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

შემოწმება 4: ცალკე შეხედეთ კონტეინერის გზას

ჩატვირთული დამხმარე მარშრუტს არ ქმნის. კონტეინერს PPTP სერვერამდე გზა სჭირდება, და ჰოსტის გადამისამართებამ GRE ორივე მიმართულებით უნდა დაუშვას: iptables -L FORWARD -v -n გვიჩვენებს, მიიღება თუ არა 47 ოქმი და მოძრაობენ თუ არა მთვლელები. Docker-ის masquerade წესები TCP-ს და UDP-ს თარგმნიან, არა 47 ოქმს, ამიტომ ხიდურ კონტეინერს შეიძლება დასჭირდეს გამოკვეთილი forward ნებართვა და ზოგ ჰოსტზე საკუთარი თარგმანის წესი. ასევე დაადასტურეთ, რომ კონტეინერს აქვს მისი იმიჯის მიერ მოსალოდნელი PPP მოწყობილობის მხარდაჭერა.

წესის ტექსტს კი არა, მთვლელებს კითხულობთ. წესი, რომელიც არსებობს და არაფერს ემთხვევა, მორთულობაა.

შემოწმება 5: დაამტკიცეთ, რომ GRE თვალყურს ადევნებენ, შემდეგ გადაწყვიტეთ PPTP-ზე

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

თავად PPTP მოძველებულია და MS-CHAPv2 სუსტია. თუ სერვერი ასევე გვთავაზობს L2TP/IPsec, IKEv2 ან WireGuard-ს, ერთ-ერთზე გადასვლა პრობლემების ამ მთელ კლასს აშორებს.

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