GRE-ის ჩაწერის შეცდომები pptpd-ზე პაროლის პრობლემა არ არის

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

ორი შეტყობინება, ორი განსხვავებული ხარვეზი

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

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

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

47 პროტოკოლი 47 პორტი არ არის

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

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

დააკვირდით ორივე მიმართულებას ერთდროულად სერვერზე, ნაცვლად იმისა, რომ გამოიცნოთ რომელი მხარე ყრის ტრაფიკს: tcpdump -ni any port 1723 or proto gre.

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

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

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

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

გახადეთ წესი მუდმივი დისტრიბუციის firewall სერვისის მეშვეობით, ყოველი გადატვირთვის შემდეგ ხელახლა გაშვების ნაცვლად. nftables ჰოსტზე შეადარეთ ip protocol gre როგორც input, ისე forward ჯაჭვში.

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

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

სხვა მოხსენების შესწორება /etc/ppp/pptpd-options-შია, სადაც რეცეპტი უარყოფს PAP-ს, CHAP-ს და MSCHAP-ს, კომენტარს უკეთებს შესაბამის require სტრიქონებს და ინარჩუნებს მდგომარეობის MPPE-ს. ეს რეცეპტი ერთი კლიენტური ნარევისთვის დაიწერა და ბრმად კოპირება ჩვეულებრივ შემთხვევას ამტვრევს. უარყოფის სტრიქონები წაიკითხეთ როგორც განცხადება იმაზე, თუ რა კლიენტები ჰყავდა ავტორს და არა როგორც რეკომენდაცია.

Windows კლიენტს ჩვეულებრივ სჭირდება MS-CHAPv2 MPPE-128-ით. შეინარჩუნეთ ეს მოთხოვნები და ამოიღეთ მხოლოდ ის პარამეტრები, რომლებზეც კლიენტი ნამდვილად ვერ მოილაპარაკებს.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

წაიკითხეთ კლიენტის შეცდომის ნომერი

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

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

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