რატომ არ შეუძლია მხოლოდ PPP CHAP-ს MPPE-ის მოთხოვნის დაკმაყოფილება

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

ერთი PPTP კავშირის შიგნით ორი მოლაპარაკება მიდის

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

ჩვეულებრივი CHAP არის RFC 1994-ის გამოწვევა-პასუხის გაცვლა, აგებული საერთო საიდუმლოზე და სხვა არაფერზე. MS-CHAPv2 სხვა შეტყობინებებითა და სხვა გამოსავლით სხვა გაცვლაა, სტანდარტიზებული RFC 2759-ში. საერთო სიტყვა ორ სახელში ერთადერთია, რაც მათ საერთო აქვთ მავთულზე. არც ერთი სახელი არ ამბობს, რას აწარმოებს გაცვლა, და სწორედ ეს არის ერთადერთი მნიშვნელოვანი ნაწილი.

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

შეუსაბამეთ მოთხოვნილი მეთოდი იმ გასაღებებს, რომელთა წარმოებაც შეუძლია

MPPE-ის გასაღებები PPP-ის ზოგადი თვისება არ არის. Microsoft CHAP-ის ოჯახისთვის გამოყვანა განსაზღვრულია RFC 3079-ში, და ის შეყვანად იღებს MS-CHAP გაცვლის გამოსავალს და არა საერთო საიდუმლოს. EAP მეთოდები იმავე ადგილს სხვა გზით აღწევენ, როცა ავთენტიფიკაციის სერვერი გასაღებებს აბრუნებს როგორც MS-MPPE-Recv-Key და MS-MPPE-Send-Key ატრიბუტებს. ჩვეულებრივი CHAP არც ერთ გზაზე არ ჩანს, და ეს არის ამ შეუსაბამობის არსებობის მთელი მიზეზი.

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

აქედან გამომდინარე წესი მოკლეა: თუ პროფილი MPPE-ს მოითხოვს, მეთოდი უნდა იყოს MS-CHAP-ის ვარიანტი ან EAP მეთოდი, რომლის გასაღებებსაც სერვერი აბრუნებს. მხოლოდ MS-CHAPv2-ის უარყოფა ამას არ აიძულებს, რადგან MS-CHAPv1-იც გამოიმუშავებს გასაღებებს და ხელმისაწვდომი რჩება, თუ ცალკე არ უარყვეს; ორივეს უარყოფა ტოვებს ჩვეულებრივ CHAP-სა და PAP-ს, რომლებიც არაფერს გამოიმუშავებენ და მოთხოვნას შეუსრულებელს ხდიან. დაასახელეთ მიღებული მეთოდი ცხადად იმის ნაცვლად, რომ ჩამოთვალოთ ის, რაც არ მოგწონთ. დაშიფვრის მოთხოვნის მიტოვება კლიენტის დასაკავშირებლად დაქვეითებაა და არა შეკეთება.

წაიკითხეთ სერვერის პარამეტრები კლიენტის რედაქტირებამდე

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

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

წაიკითხეთ გამოსავალი როგორც ხელშეკრულება და არა დროშების სია. სტრიქონი, რომელიც MPPE-ს მოითხოვს და ამავდროულად უარყოფს MS-CHAP-ის ორივე ვარიანტს, ვერც ერთ კლიენტს არ შეუძლია შეასრულოს, და MS-CHAP მეთოდის მოთხოვნის არარსებობა ღიად ტოვებს კარს გასაღების არამომცემი გაცვლებისთვის. შემდეგ შეამოწმეთ, ვის აქვს საერთოდ ავთენტიფიკაციის უფლება, რასაც საიდუმლოთა ფაილი წყვეტს:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

იპოვეთ მარცხი PPP-ის ფაზის მიხედვით

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

დაგეგმეთ გასვლა მანამ, სანამ ძველი საბოლოო წერტილი გამოირთვება

MPPE კავშირის დაცვის ისტორიული მექანიზმია და მისი არსებობა PPTP-ს ახალი განლაგებისთვის გონივრულ არჩევანად არ აქცევს. Microsoft-ის მიმდინარე სახელმძღვანელო უკვე ეწინააღმდეგება PPTP-ს და წინასწარ გაზიარებული გასაღების მქონე L2TP/IPsec-ს ახალი დისტანციური წვდომის განლაგებისთვის. ძველი საბოლოო წერტილის ცოცხლად შენარჩუნება არსებულ სერვისზე გადაწყვეტილებაა და არა შაბლონი შემდეგისთვის.

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

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