გაყოფილი გვირაბი საჯარო ჰოსტს ASA-ის NAT წესებიდან არ ათავისუფლებს

split-include მარშრუტი საჯარო ჰოსტს გვირაბში ექაჩება, სადაც ASA-მ უნდა გააკეთოს hairpin და თარგმნოს წყარო. რომელიმე ნაბიჯის გამოტოვება ნაკადს წყვეტს.

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

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

მითი: გაყოფილი გვირაბი firewall-ს გზიდან აშორებს

რწმენა არის, რომ კერძო დიაპაზონების გარეთ ნებისმიერი დანიშნულება ლოკალურ ინტერნეტ კავშირზე რჩება, ამიტომ firewall-ი მას ვერასდროს ხედავს და ვერასდროს სჭირდება წესი. ეს მხოლოდ მაშინაა მართალი, სანამ დანიშნულება გვირაბის სიაში არ არის. იმ მომენტში, როცა ოპერატორი საჯარო ჰოსტს split-include ACL-ში ამატებს, კლიენტი ამ ტრაფიკს გვირაბში აგზავნის, და ASA-მ უნდა დაამარშრუტოს, გაფილტროს და თარგმნოს ის, როგორც ნებისმიერი სხვა გაშიფრული ნაკადი. კლიენტზე არაფერი შეცვლილა დანიშნულებების სიის გარდა.

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

რას აკეთებს split-include მარშრუტი სინამდვილეში

Cisco ASA დისტანციური წვდომის კონფიგურაციაში ჯგუფური პოლიტიკა შეიცავს split-tunnel-policy tunnelspecified და split-tunnel-network-list, რომელიც სტანდარტულ ACL-ს ასახელებს. ამ ACL-ის ყოველი permit ხაზი დანიშნულებაა, რომელიც კლიენტმა გვირაბში უნდა გაგზავნოს, დანარჩენი კი კვლავ ლოკალურ ნაგულისხმევ მარშრუტს იყენებს.

ერთი ჰოსტის დამატება ერთი ხაზია და ეს არის ცვლილების ერთადერთი ნაწილი, რომელსაც კლიენტი ხედავს: access-list RA-SPLIT standard permit host 203.0.113.20.

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

პაკეტი იმავე ინტერფეისზე შემოდის და გადის

ახლა თვალი ადევნეთ ნაკადს გაშიფვრის შემდეგ. პაკეტი VPN გვირაბის მეშვეობით გარე ინტერფეისზე შემოვიდა, მისი დანიშნულება საჯარო მისამართია, და მარშრუტიზაციის ცხრილი მას იმავე გარე ინტერფეისიდან ინტერნეტისკენ უკან აგზავნის. ერთ ინტერფეისზე შემავალი და გამავალი ტრაფიკი უგულებელყოფილია, თუ ASA-ს ამის უფლება არ მიეცა, და სწორედ ამას აკეთებს same-security-traffic permit intra-interface. ამის გარეშე კავშირი მარცხდება ისე, რაც მარშრუტიზაციის პრობლემად გამოიყურება და არც არის.

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

რატომ არ არის დანიშნულებით შეზღუდული PAT სავალდებულო

გაშიფრული პაკეტის წყაროს მისამართი კვლავ კლიენტის VPN მისამართია, ჩვეულებრივ 10.77.0.0/24-ის მსგავსი პულიდან. ამ მისამართს საჯარო ინტერნეტში მარშრუტი არ აქვს, ამიტომ პარტნიორი ან საერთოდ არ პასუხობს, ან არსად პასუხობს.

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

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static ნაწილს მნიშვნელობა აქვს. მისი გამოტოვებით წესი ფართო თარგმნად იქცევა, რომელიც განზრახულზე გაცილებით მეტ ტრაფიკს დაემთხვევა, და რიგით ადრე მდგომი ფართო identity წესი შეიძლება მთლიანად დაამარცხოს ეს. სანამ ჩათვლით, რომ თქვენი წესია შესაბამისი, შეამოწმეთ show nat detail და სექციების რიგი.

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

დაამტკიცეთ სწორი სატესტო დანიშნულებით

გამოიყენეთ თავად პარტნიორი ჰოსტი და არა ზოგადი what-is-my-ip გვერდი. ის გვერდი თითქმის დარწმუნებით split სიის გარეთაა, ამიტომ ის თქვენს ლოკალურ ინტერნეტ მისამართს გაცნობებთ და ამ გზაზე არაფერს ამბობს. გახსენით ახალი კავშირი პარტნიორ სერვისთან და ჰკითხეთ, რა წყარო დააფიქსირეს, ან გაუშვით packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed და წაიკითხეთ NAT-ისა და მარშრუტიზაციის ეტაპები სტრიქონ-სტრიქონ. კლიენტიდან traceroute უფრო სუსტი შემოწმებაა, რადგან ის უკვე მომხდარ გზას აჩვენებს და არა იმ პოლიტიკას, რომელმაც ის აირჩია.

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

ამ დიზაინის მომუშავე ვერსია მოკლეა: ერთი ჰოსტი split ACL-ში, hairpin-ის ნებართვა, ერთი დანიშნულებით შეზღუდული PAT წესი. დანარჩენი ყველაფერი ამ ამბავში მითია.

დაკავშირებული სტატიები