IPsec IPsec-ში: რომელი მისამართები უნდა ატაროს გარე გვირაბმა

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

ოთხი კარიბჭის მოდელი

გარე კარიბჭეები A და B პირველ გვირაბს აშენებენ ორ საიტს შორის. A-ს უკან შიდა კარიბჭე C დგას გავლის მისამართით 10.60.0.2, ხოლო B-ს უკან შიდა კარიბჭე D გავლის მისამართით 10.70.0.2. აპლიკაციების ქსელები C-სა და D-ს უკან ცხოვრობენ და მაგალითში ყველა მისამართი განზრახ არ ემთხვევა.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

თითოეული დონე მხოლოდ საკუთარ დაცვას ხსნის

C შიფრავს აპლიკაციის პაკეტს D-სთვის. შედეგი მისამართდება C-დან D-მდე და სწორედ ეს აღწევს A-მდე. ყველაფერი ქვემოთ დამოკიდებულია ამ გადაწერაზე.

A მას ხელახლა შიფრავს B-სთვის. B შიფრს ხსნის გარე დონეს, ხედავს პაკეტს C-დან D-მდე და გადასცემს მას ჯერ კიდევ დაშიფრულს. D ხსნის შიდა დაცვას და აწვდის აპლიკაციის პაკეტს.

ამრიგად, A და B ხედავენ შიდა ბოლო წერტილებს და მათ მეტამონაცემებს, მაგრამ არ არიან ის მხარეები, რომლებიც აპლიკაციის ტვირთს შიფრს ხსნიან. ეს დიზაინის რეალური თვისებაა და არა მტკიცება, რომ C, D ან აპლიკაციის ჰოსტები სანდოა.

გარე სელექტორები შიდა კარიბჭეებს ასახელებენ

სწორედ აქ იშლება ასეთი კონსტრუქციების უმეტესობა. პოლიტიკაზე დაფუძნებული გარე გვირაბისთვის სელექტორები, რომლებზეც თქვენ მოლაპარაკებას აწარმოებთ, უნდა შეიცავდეს იმ მისამართებს, რომლებსაც A და B რეალურად ამუშავებენ: 10.60.0.2/32 და 10.70.0.2/32, სწორი ლოკალური და დისტანციური თანმიმდევრობით.

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

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

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

გადაგზავნა და რეკურსიის ხაფანგი

სელექტორები მარშრუტიზაციას არ ცვლიან. A-მ და B-მ უნდა გადასცენ ტრაფიკი C-სა და D-ს შორის ორივე მიმართულებით, რაც ნიშნავს ჩართულ IP გადაგზავნას, გვირაბზე მიმთითებელ მარშრუტებს და მეორე მხარეს არსებულ დაბრუნების გზას.

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

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

შეისწავლეთ თარგმნა დონეების დამატებამდე

შეხედეთ ნებისმიერ წყარო NAT-ს A-სა და B-ზე, სანამ სხვა რამეს დააყენებთ. წესმა, რომელიც C-ის მისამართს გადაწერს IPsec პოლიტიკის გამოყენებამდე, შეიძლება დაარღვიოს შეთანხმებული სელექტორები და ასევე შეცვალოს, თუ რას იღებს D მეორე მხარეს.

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

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

დაამტკიცეთ fail-closed და შეამოწმეთ MTU

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

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

გაითვალისწინეთ ორივე ინკაპსულაცია. მომუშავე IKE მცირე პაკეტების შედეგია და სრული ზომის აპლიკაციის პაკეტები მაინც შეიძლება ჩავარდეს ორი სათაურის დამატების შემდეგ; შეამოწმეთ ცნობილი ტვირთის ზომით რეალურ გზაზე და ნუ ჩათვლით, რომ რიცხვები იკრიბება. არითმეტიკა ადვილია, გზა არა.