Cisco ASA-ის tunneled ნაგულისხმევი მარშრუტი: როდის მოქმედებს ის რეალურად

დისტანციური წვდომის მომხმარებელი ASA-ს იქით ვერაფერს აღწევს, მაშინ როცა იგივე სერვერი პასუხობს ping-ებს შიდა LAN-იდან. გვირაბი ადის, კლიენტი იღებს მისამართს pool-იდან, და პაკეტი მაინც გადის ინტერნეტის ნაგულისხმევი მარშრუტით ან ქრება. ეს ნიმუში ჩვეულებრივ ნიშნავს, რომ გაშიფრულმა ტრაფიკმა საკუთარი მარშრუტი ვერ იპოვა და ჩვეულებრივ ნაგულისხმევ მარშრუტზე ჩამოვარდა. გამოსწორება კიდევ ერთი NAT წესი არ არის; გამოსწორება tunneled ნაგულისხმევი მარშრუტია.

დაიწყეთ სიმპტომით, არა კონფიგურაციით

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

show vpn-sessiondb-ში გვირაბი ჯანმრთელად გამოიყურება, და სწორედ ამიტომ აგრძელებენ ადამიანები IKE-ის debug-ს.

ACL-ით ჩამოგდებისგან ამას მიმართულება განასხვავებს. ACL-ით ჩამოგდება ლოგირდება და ითვლება, ხოლო მარშრუტის ნაკლებობა ქმნის ძებნის ჩავარდნას შესაბამისი ჩანაწერის გარეშე. გაუშვით show route კლიენტის დანიშნულებისთვის და წაიკითხეთ, რა აირჩია ASA-მ რეალურად, მათ შორის აირჩიეს თუ არა ნაგულისხმევი მარშრუტი და რომელი.

რით განსხვავდება tunneled ძებნა

Cisco-ს ASA 9.23 სტატიკური მარშრუტიზაციის გზამკვლევი აღწერს ცალკე ნაგულისხმევ მარშრუტს გაშიფრული VPN ტრაფიკისთვის, რომელსაც არც სტატიკური და არც ნასწავლი მარშრუტი არ აქვს. tunneled საკვანძო სიტყვა აღნიშნავს ამ მარშრუტს, ამიტომ გაშიფრულ პაკეტს შეუძლია დაეცეს სხვა შემდეგ hop-ზე, ვიდრე ის, რომელსაც ASA იყენებს საკუთარი ტრანსპორტისთვის. უფრო კონკრეტული მარშრუტები მაინც იმარჯვებს, ამიტომაც შეუძლია კლიენტს შიდა gateway-ის გავლით მიაღწიოს 10.0.0.0/8-ს და დაკარგოს ყველაფერი დანარჩენი.

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

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

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

შეზღუდვები, რომლებიც წყვეტენ, იმუშავებს თუ არა

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

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

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

რას არ აკეთებს საკვანძო სიტყვა

ის არ ირჩევს წყაროს მისამართს, რომელსაც ASA იყენებს IKE-ის ასაგებად. გვირაბის გარე ბოლო წერტილი მიჰყვება პლატფორმის საკუთარ ინტერფეისისა და წყაროს შერჩევას, და tunneled ნაგულისხმევ მარშრუტს ამ გადაწყვეტილებაში წილი არ აქვს. მისი შეცვლა არ შეაკეთებს phase 1-ს, რომელიც არასწორი მისამართიდან იწყება.

ის ასევე არ აქცევს შემდეგ hop-ს proxy-დ. თუ დანიშნულება ელოდება HTTP CONNECT გაცვლას, ნედლი IP პაკეტების proxy ჰოსტზე გაგზავნა მოგცემთ მხოლოდ ჰოსტს, რომელიც მათ არ მარშრუტიზირებს. ნაცვლად ამისა დააკონფიგურირეთ კლიენტის მიერ მხარდაჭერილი proxy მექანიზმი.

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

შეამოწმეთ გზა თავიდან ბოლომდე

მარშრუტის დაყენების შემდეგ ზედიზედ შეამოწმეთ ოთხი რამ: show route იმ დანიშნულებისთვის, რომელიც pool-ს სჭირდება, capture ახალი შემდეგი hop-ისკენ მიმავალ ინტერფეისზე, capture თავად gateway-ზე, და დაბრუნების გზა ამ gateway-იდან pool-ის მისამართამდე. პირველი ორი ამტკიცებს, რომ ASA-მ აირჩია გზა, ხოლო ბოლო ორი — რომ იქ ვიღაც პასუხობს.

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

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