როგორ მოვახდინოთ VPN ნაკადის მოდელირება ASA packet-tracer-ით

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

ქვემოთ მოცემული მიმოხილვა ვარაუდობს, რომ ACL, NAT წესი და tunnel-group კონტექსტი თქვენ წინაშეა. მათ გარეშე გამომავალი აღწერს პოლიტიკას, რომელსაც ვერ შეამოწმებთ.

ნაბიჯი 1: დაწერეთ შიდა ნაკადი მარტივი სიტყვებით

აღწერეთ აპლიკაცია სანამ რამეს აკრეფთ. შიდა ჰოსტი, რომელიც SSH-ს ხსნის შორეული კარიბჭის მიღმა მდებარე სერვერთან, არის ერთი შიდა TCP ნაკადი კონკრეტული წყაროს პორტით. სწორედ ამ ნაკადს აფასებს ACL და VPN ფილტრი, ამიტომ სწორედ მას აკრეფთ.

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

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

ნაბიჯი 2: აირჩიეთ შესასვლელი ინტერფეისი და მიმართულება

შესასვლელი არის ინტერფეისი, რომელზეც პაკეტი ჩამოდის და არა ის, რომლითაც გადის. დაწყების LAN ჰოსტისთვის ეს არის inside ინტერფეისი. იმავე სესიის დაბრუნების პაკეტისთვის ეს არის outside ინტერფეისი და tuple ბრუნდება. დანიშნულების წყაროდ დაწერა დამაჯერებელი, მაგრამ ურელევანტური ALLOW-ის მიღების მეორე ყველაზე გავრცელებული გზაა.

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

ნაბიჯი 3: წაიკითხეთ ფაზები თანმიმდევრობით

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

NAT ხშირად ატყუებს ხალხს. თუ თარგმნილი წყარო გვირაბისთვის ტრაფიკის ამომრჩევი crypto ACL-ის გარეთ რჩება, ნაკადი შეიძლება დაშვებულ იქნას და არასოდეს ჩაფუთოს. კვალი ბეჭდავს თარგმნილ მისამართს, ამიტომ შეადარეთ ის გვირაბის საინტერესო ტრაფიკს და არა თავდაპირველ მისამართს.

ნაბიჯი 4: შეამოწმეთ რომელი გვერდის ავლები აირჩიეთ

detailed ფორმა იღებს პარამეტრებს, რომლებიც გამოტოვებენ შემოწმებებს, და Cisco ადოკუმენტირებს bypass-checks პარამეტრს, რომელიც მოიცავს ACL, VPN ფილტრს, uRPF-ს და IPsec-ის გაყალბების შემოწმებებს. მათი გვერდის ავლით მიღებული ALLOW ამბობს, რომ მარშრუტი და NAT იმუშავებდა და არა რომ პოლიტიკა რეალურ პაკეტს დაუშვებდა. ჩაწერეთ პარამეტრები შედეგის გვერდით.

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

ნაბიჯი 5: დახურეთ სხვაობა რეალური გაცვლით

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

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

რასაც კვალი ჯერ კიდევ ვერ გეტყვით

შეინახეთ ოთხი რამ ერთ ჩანაწერში: tuple, შესაბამისი NAT წესი, გვირაბი ან პოლიტიკა, რომელმაც უნდა ატაროს ნაკადი და მიმართულების სპეციფიკური დაკვირვება. მათ გარეშე გვიანდელი ინჟინერი ვერ გამოყოფს ლოკალურ პოლიტიკურ გადაწყვეტილებას ჩამოყალიბებული მართვის სიბრტყისა და მომუშავე სერვისისგან. პირველი მარცხი, რომელსაც წარმატება მოჰყვება, ასევე არ არის მტკიცებულება, რომ გვირაბი ამ დროში უნდა ასულიყო; ჩაწერეთ ფაზა და მდგომარეობის ცვლილება.

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