iOS IKEv2-დან strongSwan-მდე: შეთავაზება არ არჩეულა, გაასწორე სია
„შეთავაზება არ არჩეულა“ ნიშნავს, რომ ორი სია არასოდეს იკვეთება. გადათარგმნე SHA1 SHA-96-ად, modp1024 group 2-ად და შვილობილი შეთავაზებაც დააყენე.
iPhone თუნელს ხსნის, კარიბჭე არაფერს პასუხობს და ტელეფონი ზოგად შეცდომას აჩვენებს. strongSwan-ის ჟურნალი უფრო კონკრეტულია: no proposal chosen. ეს შეტყობინება ნიშნავს, რომ მისაღები შიფრული კრებულების ორი სია არასოდეს დაემთხვა, ამიტომ გაცვლა ავთენტიფიკაციის დაწყებამდე დასრულდა. ეს შესაბამისობის პრობლემაა და გამოსავალი სიების გადაკვეთაა.
სად აცხადებს კარიბჭე თავის პოლიტიკას
strongSwan პოლიტიკას კონფიგურაციაში წერს და ბოლოში მდგარი ძახილის ნიშანი წყვეტს, როგორ უნდა წაიკითხოს ის. ნიშნით სია ამომწურავია: მიიღება მხოლოდ ეს ჩანაწერები და სხვა არაფერი. ნიშნის გარეშე იგივე ხაზი უპირატესობის რიგია და დემონმა შეიძლება ის აირჩიოს, რაც არ გინდოდა. ჰკითხე, რომელი ფორმაა განლაგებული, სანამ რამეს თარგმნი, რადგან ორივე ერთი და იმავე კლიენტის მიმართ სხვადასხვაგვარად იქცევა. ჩაწერე ზუსტი ხაზი, ნიშნის ჩათვლით, და სწორედ მასთან შეამოწმე.
უფრო ფართო სიის შემომთავაზებელ კლიენტს მაინც შეუძლია დაუკავშირდეს დამაგრებულ კარიბჭეს, თუ ორივე მხარეს ერთი კომბინაცია მაინც გვხვდება. რაც ვერ მოხდება, ეს არის მოლაპარაკება დამაგრებული სიმრავლის გარეთ.
ამიტომ სხვა VPN აპიდან კოპირებული პროფილი შეიძლება მუშაობდეს იქ, სადაც შენი არ მუშაობს: სხვა აპი სხვა სიას აგზავნიდა.
სახელები უნდა დაემთხვეს და არა გაუმჯობესდეს
ორი თარგმანი ატყუებს მათ, ვინც მნიშვნელობებს strongSwan-იდან iOS-ში გადააქვს. IKE შეთავაზებაში SHA1-ად დაწერილი მთლიანობის ალგორითმი შეკვეცილი ფორმით მოძრაობს, რომელსაც iOS .SHA96-ს უწოდებს. modp1024-ად დაწერილი Diffie-Hellman ჯგუფი მე-2 ჯგუფია, რომელსაც iOS .group2-ს უწოდებს. SHA-256-ის ან მე-14 ჯგუფის ჩანაცვლება არ იმუშავებს კარიბჭესთან, რომელიც მხოლოდ ძველ წყვილს იღებს. კლიენტმა იგივე ალგორითმი უნდა აღწეროს და არა უფრო ძლიერი.
ეს მნიშვნელობები ცხადად დააყენე NEVPNProtocolIKEv2-ში. ნაგულისხმევი შეიძლება იყოს უფრო ფართო ან ვიწრო, ვიდრე შესაცვლელი პროფილი, და განსხვავება მხოლოდ მაშინ ჩნდება, როცა ხელის ჩამორთმევა ვერ ხერხდება.
შვილობილი შეთავაზება უფრო გვიან და უფრო ჩუმად ვარდება
შვილობილი უსაფრთხოების გაერთიანებაც დააკონფიგურე და არა მხოლოდ IKE. როცა მხოლოდ IKE პარამეტრები ემთხვევა, თუნელი ავთენტიფიცირდება და შემდეგ ტრაფიკს არ ატარებს, რაც გაცილებით ჩუმი მარცხია უარის თქმაზე. შვილობილის დაშიფვრა, მთლიანობა, ჯგუფი და სიცოცხლის ხანგრძლივობა იმავე ნაბიჯში დააყენე. კლიენტის ხანგრძლივობა კარიბჭის მნიშვნელობაზე ნაკლები ან ტოლი შეინახე, რადგან უფრო გრძელზე დაჟინება სხვა მიზეზით იმავე no proposal chosen შეტყობინებას იძლევა. იქაური შეუთანხმებლობა ზუსტად ისე გამოიყურება, როგორც IKE-ის შეუთანხმებლობა ჟურნალში.
სანამ კონფიგურაციაში ხარ, შეამოწმე, პროფილი სერტიფიკატებით ავთენტიფიცირდება თუ საერთო საიდუმლოთი. შეთავაზების უარი და ავთენტიფიკაციის უარი სხვადასხვა ხაზზე ჩნდება და არასწორის გასწორება ერთ დღეს გიჯდება. ყოველი ცვლილების შემდეგ ახალი კავშირით სცადე, ერთდროულად ერთი ცვლადით, რადგან ქეშირებული მდგომარეობა მალავს, რომელი პარამეტრი გადაინაცვლა.
ძველი კრებული მხოლოდ მაშინ დატოვე, როცა საჭიროა
SHA-1-ის 1024-ბიტიან ჯგუფთან დამაგრება ხიდია და არა დანიშნულება. ორივე მოძველებულია და უფრო ახალმა კლიენტებმა შეიძლება საერთოდ უარი თქვან მათზე, რაც ნიშნავს, რომ პროფილი შემდეგ მოწყობილობაზე ჩავარდება შენი მხრიდან ყოველგვარი ცვლილების გარეშე. მოეპყარი დამაგრებას როგორც დროებითს და ასეც ჩაწერე ჩანაწერში.
თუ strongSwan შენია, დაამატე თანამედროვე შეთავაზება და ნება მიეცი ორივე ბოლოს ზემოთ იმოლაპარაკოს, სანამ ძველი ჩანაწერი ძველი მოწყობილობებისთვის რჩება. წაიკითხე დემონის მდგომარეობის გამოსავალი, რომ ნახო, რომელი კრებული გამოიყენა თითოეულმა კავშირმა სინამდვილეში. შემდეგ მოხსენი კლიენტის მხრიდან დამაგრება, როცა თანამედროვე წყვილი დადასტურდება. აწეული თუნელი საკმარისი მტკიცებულება არ არის, რადგან ის შეიძლება იმ კრებულზე აწიოს, რომლის გაუქმებასაც ცდილობდი. strongSwan-ის IKEv2 დოკუმენტაცია აღწერს შეთავაზებების სინტაქსსა და strict ნიშანს.