L2TP/IPsec ვერ მუშაობს: გამოყავით IPsec, გვირაბის აუთენტიფიკაცია ან PPP შესვლა

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

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

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

L2TP საკონტროლო კავშირს შეუძლია დაამატოს მეორე, ცალკე გამოწვევა-პასუხის გაცვლა, რომელსაც მართავს საერთო საიდუმლო, რომელიც ორივე ბოლოს უნდა ჰქონდეს.

RFC 2661 ეს საკონტროლო კავშირის აუთენტიფიკაცია არასავალდებულოს ხდის, რაც ხსნის, თუ რატომ იძლევა ერთი და იგივე შეცდომა სხვადასხვა სიმპტომს ორ სერვერზე. განლაგება, რომელსაც გვირაბის საიდუმლო არასდროს დაუყენებია, საფეხურს მთლიანად გამოტოვებს; ის კი, რომელმაც მხოლოდ ერთ მხარეს დააყენა, ვარდება მანამ, სანამ PPP შემოთავაზდება. შემდეგ PPP აუთენტიფიცირებს მომხმარებელს PAP, CHAP ან MSCHAPv2-ით და სახელს გადასცემს ანგარიშების საცავს, რომელიც შეიძლება იყოს ლოკალური, chap-secrets-ში ან RADIUS-ზე. არასწორი პაროლი ამ მომენტში მაინც გტოვებთ მომუშავე გვირაბით და ჩავარდნილი სესიით.

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

დაიწყეთ ipsec --version-ით, რომ იცოდეთ სტატუსის გამონატანი strongSwan-ისაა თუ Libreswan-ის. შემდეგ წაიკითხეთ სერვერის ჟურნალი და არა კლიენტის დიალოგი, რადგან სერვერი იწერს, რომელმა საფეხურმა თქვა უარი.

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

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

პირველი საფეხური: აქვს IPsec-ს ასოციაცია?

გაუშვით ipsec statusall strongSwan-ზე ან ipsec whack --status Libreswan-ზე და მოძებნეთ დამყარებული შვილობილი ასოციაცია არანულოვანი მრიცხველებით. ip xfrm state ორივეზე ბირთვის ხედს აჩვენებს. დაყენებული SA წყვილი მზარდი მრიცხველებით ნიშნავს, რომ პირველი საფეხური დასრულდა და შეგიძლიათ გააგრძელოთ.

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

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

მეორე საფეხური: აუთენტიფიცირდა L2TP საკონტროლო კავშირი?

როცა IPsec მუშაობს, დააკვირდით L2TP დემონს დამყარებულ მდგომარეობამდე მიმავალ საკონტროლო კავშირს, რადგან PPP მანამდე ვერ დაიწყება. საკონტროლო კავშირზე უარი ნიშნავს, რომ გვირაბის საიდუმლო ბოლოებს შორის განსხვავდება, ან ერთი ბოლო ითხოვს საიდუმლოს, რომელსაც მეორე არასდროს აგზავნის. კლიენტები ხშირად აჩვენებენ ერთ ველს shared secret ეტიკეტით და ის ჩვეულებრივ IPsec-ს ეკუთვნის და არა L2TP-ს. მისი შევსება გვირაბის საიდუმლოს არ აყენებს, ხოლო გასუფთავება არ თიშავს მას.

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

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

მესამე საფეხური: PPP ანგარიშს უარყოფს?

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

Linux სერვერზე შეამოწმეთ პარამეტრების ფაილი, რომელსაც დემონი PPP-ს გადასცემს, ჩვეულებრივ /etc/ppp/options.xl2tpd, და დაადასტურეთ, რომელი მეთოდები მიიღება და სად წყდება ანგარიშები. სახელი, რომელიც RADIUS-ში არსებობს, მაგრამ ლოკალურ საიდუმლოების ფაილში არა, სუფთად ვარდება და არასწორ პაროლს ჰგავს. შემდეგ შეამოწმეთ, რომ კლიენტი სთავაზობს მეთოდს, რომელსაც სერვერი იღებს და არა უფრო ძლიერს, რომლის მოლაპარაკებასაც სერვერი უარყოფს. წინასწარ გაზიარებული გასაღების შეცვლა ამ საფეხურის შესაკეთებლად ნახევარ დღეს ფლანგავს და არაფერს ცვლის.

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