IKE იდენტობა თუ ენდპოინტის მისამართი: არ აურიოთ
FQDN ტიპის IKE იდენტობა ლიტერალური ავთენტიფიკაციის მნიშვნელობაა და არა უკუ DNS ძებნა. გამოყავით ენდპოინტის მისამართი, ლოკალური იდენტობა და მოსალოდნელი peer.
წაიკითხეთ FQDN იდენტობად მონიშნული ველი ლიტერალურ სტრიქონად და არა თქვენი საჯარო მისამართის უკუ DNS სახელის მოთხოვნად. strongSwan-ის პარსერში ეს ზუსტად ის არის, სტრიქონი, და მისი წაკითხვა არასოდეს ხსნის მას ენდპოინტად. ეს ფაქტი თავისთავად აშორებს ყველაზე გავრცელებულ ყურადღების გაფანტვას, როცა peer-ისთვის იდენტიფიკატორებს ირჩევთ. ქვემოთ მოცემული შემოწმებები ხელს უშლის სამი ჩართული მნიშვნელობის ერთში შერწყმას.
ეტიკეტი ძებნა არ არის
მომწოდებლების ინტერფეისები სიტყვებს FQDN და hostname თავისუფლად იყენებენ, და ყუთზე დაწერილი ეტიკეტი არაფერს ამბობს მის უკან არსებულ კოდირებაზე. მოწყობილობამ, რომელიც ველს Client FQDN-ს უწოდებს, შეიძლება გაგზავნოს FQDN, ელფოსტის ფორმის სტრიქონი ან შიშველი მისამართი. მოეპყარით ტექსტსა და ტიპს როგორც ორ ცალკე გადაწყვეტილებას და ჩაწერეთ ორივე.
ლიტერალურ იდენტობაში არაფერი მოითხოვს DNS-ს. ეს არის მტკიცება, რომელსაც მეორე მხარე ამოწმებს და არა სახელი, რომელიც ქსელმა უნდა გადაწყვიტოს.
სამი ცალკე მნიშვნელობა, ცალ-ცალკე დაწერილი
ერთი კონფიგურაციის ეკრანის უკან სამი სამუშაო დგას და მათი შერწყმა ძვირი შეცდომაა. ერთი მნიშვნელობაა ენდპოინტის მისამართი, რომელიც წყვეტს, სად წავიდეს პაკეტები. მეორე არის ლოკალური იდენტობა, რომელსაც ეს peer წარადგენს, ხოლო მესამე არის იდენტობა, რომელსაც შორეული მხრიდან ელოდებით მის ავთენტიფიკაციამდე. ჩაწერეთ ისინი სამ სტრიქონად ცვლილების ბილეთში, რადგან ნაკლები აღწერს VPN-ს და არა ურთიერთობას.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
მაგალითის იდენტობები უნდა შეირჩეს და ავტორიზდეს განლაგების ნაწილად. ეს არის მტკიცებები, რომლებსაც ავთენტიფიკაცია ამოწმებს და არა სერტიფიკატები, რომლებიც ნებისმიერ peer-ს სანდოს გახდის, ამიტომ დამაჯერებლად გამოიყურება სტრიქონი არაფერს ავტორიზებს.
ტიპი მნიშვნელობის ნაწილია
strongSwan იდენტობების ცნობარი ჰყოფს FQDN-ს, ელფოსტის ფორმის მნიშვნელობებს, IP მისამართებსა და სხვა კოდირებებს, ამიტომ კოდირება ისევე მნიშვნელოვანია, როგორც სიმბოლოები. ორმა მოწყობილობამ შეიძლება მიიღოს ერთი და იგივე ტექსტი სხვადასხვა ტიპის ქვეშ და მაინც უარი თქვას ერთმანეთზე. შენიშვნა, რომელიც მნიშვნელობას ტიპის გარეშე ინახავს, ნახევარი კონფიგურაციაა.
ჰკითხეთ მომწოდებელს, რომელ ტიპს აგზავნის მოწყობილობა სინამდვილეში, და დაადასტურეთ დეკოდირებით და არა ინტერფეისის ეტიკეტით. გამოცნობილი ტიპი არის შეუსაბამობა, რომელიც შემდეგ ცვლილებას ელოდება.
თითოეულმა მხარემ უნდა დააკმაყოფილოს მეორე
თითოეული მხარის ლოკალური იდენტობა უნდა გაიაროს მეორე მხარის ავთენტიფიკაციის პოლიტიკა. ეს არ არის იგივე, რაც ერთი სტრიქონის ჩასმა ორივე მოწყობილობის ყველა იდენტობის უჯრაში, რაც ის მოკლე გზაა, რომელიც ქმნის კონფიგურაციას, რომლის გამართვაც ვერავინ შეძლებს.
სერტიფიკატით ავთენტიფიკაცია ამატებს საკუთარ მოთხოვნებს, რადგან სერტიფიკატის იდენტობა და ნდობის პირობები თქვენს მიერ აკრეფილი IKE იდენტობის გვერდით დგას. მხოლოდ IKE იდენტობის დამთხვევა არ ავტორიზებს სერტიფიკატიან peer-ს.
სად არის DNS მნიშვნელოვანი და რას აძალებს თქვენი ვერსია
აღმოჩენისთვის გამოყენებული გეითვეის hostname ნამდვილად საჭიროებს მომუშავე DNS-ს, და ეს მოთხოვნა ეკუთვნის ენდპოინტის პოვნას და არა აკრეფილი იდენტობის რომელიმე უკუ ძებნას. ბილეთში ცალ-ცალკე შეინახეთ ორივე, რადგან აღმოჩენის ჩავარდნა და იდენტობის შეუსაბამობა კლიენტის ჟურნალში მსგავსად იკითხება და სხვადასხვა ადგილას რემონტდება.
წაიკითხეთ იმ პროდუქტისა და ვერსიის პარსერი, რომელსაც რეალურად ამუშავებთ, ტიპის მომთხოვნი სინტაქსის კოპირებამდე, რადგან strongSwan-ის ძველი გამოშვებები სხვაგვარად იქცეოდნენ და სხვა მომწოდებლები საკუთარ შეზღუდვებს ამატებენ. როცა ორ კიდეს ადარებთ, ოთხი რამ ერთად დაიჭირეთ: მოსალოდნელი იდენტობა, წარმოდგენილი იდენტობა, ტიპი და ავთენტიფიკაციის შეცდომა. ეს ნაკრები შეუსაბამობას მტკიცებულებად აქცევს და არა აზრად.