რა შედის IPsec-ის შეთავაზებაში? IKE და ESP ველები
შეთავაზება ერთი სრული შეთავაზებაა და არა ალგორითმების ტომარა. ნახეთ, რომელი ველები ეკუთვნის IKE-ს და რომელი ESP-ს, და რატომ უარყოფს ერთი შეუსაბამობა მთელ კრებულს.
IKE იწყება, ორივე მხარე აცხადებს AES-ს, და გვირაბი მაინც ვარდება NO_PROPOSAL_CHOSEN-ით. ჟურნალი ასახელებს შეთავაზებას, მაგრამ არა იმ ველს, რომელიც არ დაემთხვა. შეთავაზება ერთი სრული შეთავაზებაა, და ერთი შეუთავსებელი ველი ბათილად აქცევს მთელ კომბინაციას და არა მხოლოდ იმ სტრიქონს. მისი, როგორც დამოუკიდებელი ალგორითმის არჩევანის ტომრის, წაკითხვა ჩვეულებრივი მიზეზია იმისა, თუ რატომ რჩება შეუსაბამობა უხილავი.
ორი მოლაპარაკება ცალკეული შეთავაზებების სიებით
IKEv2 აშენებს ორ უსაფრთხოების ასოციაციას. პირველი არის IKE SA, რომელიც იცავს თავად კონტროლის გაცვლას, ხოლო მეორე არის CHILD SA, რომელიც თქვენს ტრაფიკს ESP-ის მეშვეობით გადააქვს. თითოეულს აქვს საკუთარი შეთავაზებების სია, და მხარეს შეუძლია ერთი მიიღოს და მეორე უარყოს.
ეს გაყოფა ხსნის ჩვეულებრივ დაბნეულობას: მომუშავე IKE SA მხოლოდ იმას ამტკიცებს, რომ კონტროლის არხის ალგორითმები დაემთხვა. თუ CHILD შეთავაზება ვარდება, გვირაბი ვერც ერთ პაკეტს ვერ გადაიტანს, მიუხედავად იმისა, რომ პირველი ფაზა დასრულებულია და ჟურნალები ზემოთ ჯანმრთელად გამოიყურება.
თითოეული სიის შიგნით თანმიმდევრობასაც აქვს მნიშვნელობა. პასუხისმგებელი ირჩევს ინიციატორის დალაგებული შეთავაზებებიდან, ამიტომ ფართოდ თავსებადი ჩანაწერის ვიწროზე ზემოთ გადატანა ცვლის, რომელი კრებული დამონტაჟდება, თუმცა არც ერთი ალგორითმის სახელი არ იცვლება. დაამაგრეთ ეს თანმიმდევრობა კონფიგურაციაში და ნუ დაეყრდნობით ნაგულისხმევებს. სტაბილური თანმიმდევრობა საიტებს შორის ჟურნალების შედარებასაც აზრიანს ხდის.
რომელი ველები ეკუთვნის რომელ შეთავაზებას
ველების კრებული მცირეა, მაგრამ ორ მოლაპარაკებაში ერთნაირი არ არის. წაიკითხეთ ცხრილი სტრიქონ-სტრიქონ, რადგან ერთი სვეტის ველი შეიძლება მეორეში არ იყოს. სინტაქსი განსხვავდება იმპლემენტაციის მიხედვით; strongSwan-ის შეთავაზებების დოკუმენტაცია ერთი კონკრეტული ცნობარია.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
დაშიფვრის ველი ასახელებს შიფრს და უმეტეს სინტაქსში მისი გასაღების სიგრძეს. მთლიანობის ველი ასახელებს ჰეშს, რომელიც გამოიყენება დაშიფრული ტექსტის ავთენტიფიკაციისთვის, ხოლო PRF ასახელებს ფუნქციას, რომელიც გასაღების მასალას აწარმოებს IKE SA-სთვის. DH ჯგუფი ამყარებს ახალ საერთო საიდუმლო მასალას, ამიტომ ის ორივე მხარეს ჩნდება, მაგრამ სხვადასხვა მიზნით.
გაფართოებული მიმდევრობის ნომრები მხოლოდ მონაცემთა გზას ეკუთვნის. ისინი აფართოებენ მიმდევრობის სივრცეს და მოლაპარაკება მიმდინარეობს CHILD შეთავაზების ნაწილად, ამიტომ იქაური შეუსაბამობა უარყოფს CHILD შეთავაზებას და IKE SA-ს ხელუხლებლად ტოვებს.
როგორ ირჩევა ერთი სრული შეთავაზება
თითოეული შეთავაზება კრებულია, და პასუხისმგებელი ეძებს კრებულს, სადაც ყოველი სავალდებულო ველი მისაღებია. ორი სია შეიძლება ორივე შეიცავდეს AES-ს და SHA-256-ს და მაინც არ ჰქონდეს თავსებადი ჩანაწერი, რადგან გასაღების სიგრძე, PRF ან DH ჯგუფი განსხვავდება. შედარება ხდება შეთავაზებით, და არა ალგორითმით.
როცა არაფერი ემთხვევა, პასუხისმგებელი აგზავნის NO_PROPOSAL_CHOSEN-ს იმ SA ტიპით, რომელიც ვარდა. წაიკითხეთ, რომელ შეთავაზებების სიას ეხება შეტყობინება, სანამ კონფიგურაციას შეასწორებთ; ESP ალგორითმების შეცვლა მაშინ, როცა IKE შეთავაზება უარყოფილია, ხარჯავს გამართვის ერთ ციკლს.
ღირს იცოდეთ არჩევანის ქცევა, როცა პროფილს აწყობთ. ზოგი იმპლემენტაცია ინიციატორის თანმიმდევრობას ანიჭებს უპირატესობას, სხვები ლოკალური პოლიტიკის მიხედვით გადაალაგებენ, ამიტომ ორ ვენდორს შორის მომუშავე კრებული შეიძლება გაქრეს როცა შეაბრუნებთ, რომელი მხარე იწყებს კავშირს.
AEAD ველს აშორებს და არა ამატებს
AES-GCM და ChaCha20-Poly1305 ერთ ოპერაციაში ავთენტიფიცირებენ და შიფრავენ. როცა რომელიმე მათგანი ESP-სთვის აირჩევა, მთლიანობის ალგორითმი ცალკე არ მოლაპარაკდება, რადგან AEAD კონსტრუქცია უკვე ფარავს მას. ამიტომ AES-GCM-ის SHA-256-თან დაწყვილებული შეთავაზება საუკეთესო შემთხვევაში ზედმეტია, ხოლო უარესში უარყოფილი.
PRF IKE მხარეს მაინც ცალკეა, რადგან ის გასაღებებს აწარმოებს კონტროლის არხისთვის და არა იცავს დატვირთვას. ამიტომ IKE შეთავაზებას შეუძლია კანონიერად დააკავშიროს AEAD შიფრი PRF-თან და DH ჯგუფთან, მაშინ როცა შესაბამისი ESP შეთავაზება მხოლოდ AEAD შიფრს და არასავალდებულო PFS ჯგუფს ჩამოთვლის.
გასაღების სიგრძე დაშიფვრის ნიშნის ნაწილია, ამიტომ AES-128-GCM და AES-256-GCM სხვადასხვა შეთავაზებაა. სახელმძღვანელოდან კოპირებული პროფილი, რომელიც 256-bit გასაღებებს ვარაუდობდა, არ დაემთხვევა 128-bit-ისთვის კონფიგურირებულ ბოლო წერტილს, თუმცა ორივე სტრიქონი ამბობს AES-GCM-ს. ორ მხარეს შეუძლია შიფრების ოჯახზე შეთანხმება და მაინც უარყოს ერთმანეთი ტირეს შემდეგ მდგომი რიცხვის გამო.
წაიკითხეთ დაყენებული SA და არა კონფიგურაცია
კონფიგურირებული შეთავაზებების სია შეთავაზებაა, ხოლო დაყენებული SA შედეგია. strongSwan-სა და Linux-ის ბირთვზე ორივე ხედი ხელმისაწვდომია:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ბეჭდავს თითოეული SA-სთვის შეთანხმებულ ალგორითმებს, მათ შორის იყენებს თუ არა CHILD AEAD-ს. ip xfrm state გვიჩვენებს, რა დააყენა ბირთვმა რეალურად, და სწორედ აქ მოწმდება, რომ გასაღების განახლება არ დაბრუნდა თქვენგან დოკუმენტირებულისგან განსხვავებულ კრებულზე.
შესწორების შემდეგ შეინახეთ ეს გამონატანი კონფიგურაციის გვერდით. როცა კლიენტის განახლება ცვლის ნაგულისხმევებს, ჩაწერილი კრებული გაძლევთ შედარების საწყის ხაზს, და შედარება მიუთითებს გადაადგილებულ ველზე, ნაცვლად გამოძიების თავიდან დაწყებისა.