კავშირი ხუთშაბათს მუშაობდა, განახლება პარასკევს გაიშვა, ხოლო ორშაბათს კლიენტი “connecting”-ზე ტრიალებს და ნებდება. იგივე ლეპტოპი, იგივე სერვერი, იგივე ანგარიში, იგივე წინასწარ გაზიარებული გასაღები. პროფილში არაფერი შეცვლილა, ამიტომ აშკარა ეჭვმიტანილები, პაროლი და firewall, თქვენს დროს ხარჯავენ.

რაც შეიცვალა, არის იმ ტრანსფორმაციების სია, რომლებსაც თქვენი მანქანა სთავაზობს. Ubuntu-ზე გამოყენებული ორივე IPsec სტეკი, strongSwan და Libreswan, ყრის იმ ალგორითმებს, რომლებსაც აღარ მიაჩნიათ უსაფრთხოდ, ხოლო მათ წინ მდგარ NetworkManager-ის დანამატს აქვს საკუთარი სია, რომელიც სხვა გრაფიკით მოძრაობს. 3DES-ზე, SHA1-ზე და 1024 ბიტიან Diffie-Hellman ჯგუფზე მიმაგრებულ სერვერს შეიძლება საბოლოოდ ვერაფერი ესმოდეს, რასაც იღებს.

რა შეცვალა განახლებამ სინამდვილეში

IKEv1-ის წინადადებას ორი ფენა კვებავს. დემონი აწვდის კომპილირებულ ნაგულისხმევ წინადადებების კომპლექტს, ხოლო L2TP დანამატი ან მას ეყრდნობა, ან საკუთარ სიას აძლევს. NetworkManager-l2tp 1.2.16-მდე დანამატი მას ეყრდნობოდა, ამიტომ თქვენი წინადადება იყო ის, რაც დაყენებულ დემონს გონივრულად მიაჩნდა. 1.2.16-დან დანამატი აგზავნის დოკუმენტირებულ სიას, რომელიც Windows და Apple კლიენტების მიხედვით არის შედგენილი, და ეს სია უფრო ფართოა ვიდრე ძველი ნაგულისხმევი, თუმცა უკვე არ შეიცავს რიგის სათავეში ყველა ძველ კომბინაციას.

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

იმავე არეალში უფრო პატარა ხაფანგია. ორი დემონი ელიფსური მრუდის Diffie-Hellman ჯგუფებს სხვადასხვანაირად წერს, ერთი წერს ecp384-ს, მეორე კი ecp_384-ს. ჩასვით არასწორი მართლწერა Advanced დიალოგში და დემონი უარყოფს პარამეტრს, როგორც გაურჩეველს, რაც ჟურნალში ჩანს როგორც მოლაპარაკების პრობლემა და არა როგორც კონფიგურაციის ბეჭდვითი შეცდომა.

წაიკითხეთ წარუმატებლობა, სანამ რამეს შეცვლით

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

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

შემდეგ წაიკითხეთ თავად გაცვლა. strongSwan-ზე დემონი წერს journal-ში მიმდინარე გამოშვებაზე და /var/log/syslog-ში უფრო ძველზე, და საინტერესო ნაწილი ის წინადადებაა, რომელსაც აგზავნის, და არა ბოლო ხაზი. თქვენ ეძებთ ფორმულირებას იმაზე, რომ შესაბამისი წინადადება არ არის, რაც ალგორითმის პრობლემაა; ავთენტიფიკაციის წარუმატებლობას, რომელიც გასაღებზე ან ანგარიშზე მიუთითებს; ან უბრალო timeout-ს, რომელიც ხელმისაწვდომობაზე მიუთითებს.

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

1 ფაზა და 2 ფაზა ცალკეული ფსონებია

IKEv1 ორჯერ მოლაპარაკებს. მთავარი რეჟიმი IKE უსაფრთხოების ასოციაციას აშენებს დაშიფვრის ალგორითმისგან, მთლიანობის ალგორითმისგან, Diffie-Hellman ჯგუფისგან და ავთენტიფიკაციის მეთოდისგან. სწრაფი რეჟიმი შემდეგ აშენებს ESP ასოციაციას, რომელიც L2TP-ს გადაიტანს. სერვერი თავისუფალია მიიღოს პირველი და უარყოს მეორე, ამიტომ ნახევრად სწორი პროფილი უფრო გვიან ვარდება, ვიდრე ელოდებით, და სხვა შეცდომას ჰგავს.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

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

შეცვალეთ ერთი ველი, შემდეგ გაიმეორეთ ტესტი

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

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

დაკავშირებული სტატიები