ASA-ის identity NAT IOS-ის NAT გამონაკლისის წინააღმდეგ VPN ტრაფიკისთვის

ფილიალი ინტერნეტ PAT-სა და site-to-site VPN-ს ერთსა და იმავე Cisco გეითვეიზე ამუშავებს და VPN წყვეტს მუშაობას იმ მომენტში, როცა NAT ემატება. გვირაბის შიგნით არსებული მისამართები აღარ ემთხვევა იმას, რასაც crypto ACL იცავს, ან მოპირდაპირე მხარე ხედავს თარგმნილ მისამართებს, რომლებზეც მარშრუტი არ აქვს. Cisco ამას ორ ადგილას წყვეტს: ASA ირჩევს NAT წესს, რომელიც მისამართს საკუთარ თავზე ასახავს, ხოლო IOS ACL-ის deny-ით ნაკადს თარგმანის წესის გარეთ ინარჩუნებს. ორივე ინარჩუნებს საწყის მისამართებს და არც ერთი არ არის NAT დამუშავების გვერდის ავლა.

ჩაწერეთ ნაკადი წესის არჩევამდე

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

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

ASA-ის identity NAT წესია და არა გვერდის ავლა

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

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

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

თავად ASA-ზე მართვის წვდომა ცალკე შემთხვევაა. თუ მართვის ტრაფიკისთვის identity NAT-ს იყენებთ, მოქმედებს გამოშვებაზე დამოკიდებული route-lookup მოთხოვნა და VPN-ის მაგალითიდან კოპირებული ფართო გამონაკლისი SSH-ს არ გამოასწორებს.

IOS-ის NAT ACL-ში deny ნიშნავს, რომ აქ არ არის არჩეული

IOS-ზე ინტერნეტ NAT-ს წყაროების სია მართავს და ეს ACL ფილტრი არ არის, არამედ კლასიფიკატორია. Permit სტრიქონი ტრაფიკს თარგმანისთვის ირჩევს; deny სტრიქონი ნიშნავს, რომ პაკეტი აქ არ არის არჩეული. ეს deny არ არის პაკეტის ჩაგდების ბრძანება, როგორც ეს ინტერფეისის ACL-ის deny-ს შემთხვევაშია.

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

მინიმალური IOS განლაგება deny-ს permit-ის ზემოთ ათავსებს იმავე სიაში და overload წესს ამ სიაზე მიმართავს. მაშინ crypto ACL იცავს იმავე წყვილს, რომელსაც deny თარგმანიდან გამორიცხავს.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

ერთი შემოწმებადი კითხვა ორივე მოდელისთვის

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

ASA-ზე აჩვენეთ nat detail და თარგმანების ცხრილი; IOS-ზე ip nat translations და შესაბამისი ACL მთვლელები. წესი, რომელიც არასოდეს იზრდება, არასოდეს ყოფილა არჩეული და ეს მიუთითებს თანმიმდევრობაზე, ინტერფეისზე ან მიმართულებაზე და არა crypto კონფიგურაციაზე.

სად ცდება კონფიგურაცია ჩვეულებრივ

ხშირი ხარვეზები მექანიკურია. deny permit-ის ქვემოთაა და არასოდეს ემთხვევა. კლასიფიკატორი არასწორი მიმართულებით გამოიყენება, ამიტომ საპასუხო ნაკადი ითარგმნება. identity წესი ფარავს სწორ მისამართებს, მაგრამ არასწორ ინტერფეისთა წყვილს. Crypto ACL იცავს ქვექსელს, რომელიც აღარ ემთხვევა იმას, რასაც NAT წესი წარმოადგენს.

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