Cisco ASA-დან Azure VPN-მდე: ტრაფიკის სელექტორის პრეფიქსების წყვილები

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

კონფიგურაციამდე ჩაწერეთ ოთხი ობიექტი

დაიწყეთ ASA-ის გამოშვებითა და პლატფორმით, საჯარო ბოლო წერტილით, Azure VPN კარიბჭის ტიპითა და SKU-ით და ლოკალური ქსელის კარიბჭით, რომელიც თქვენს მხარეს წარმოადგენს. ეს ოთხი სახელი ლექსიკაა ყველაფრისთვის, რაც მოჰყვება და თითოეულს განსხვავებული მფლობელი ჰყავს, როცა რაღაც ფუჭდება.

თუ ამ ორი მათგანი ჯერ კიდევ ვარაუდია, გაჩერდით. ლოკალური ქსელის კარიბჭის არასწორი პრეფიქსების სია რეგულირების პრობლემა არ არის.

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

crypto map-ის დიზაინი და tunnel interface-ის დიზაინი სხვადასხვა კონფიგურაციაა და ერთის შაბლონი მეორისთვის ძალაში არ შედის პირის მისამართის რედაქტირებით. ჩაწერეთ, რომელს აშენებთ სანამ რამეს ჩასვამთ, რადგან შეუსაბამობა მოგვიანებით სელექტორის პრობლემად ვლინდება და არა კონფიგურაციის შეცდომად. Microsoft-ის ASA-ის ურთიერთთავსებადობის სახელმძღვანელო ორივე ნიმუშს მოიცავს და ამბობს, რომელ Azure კარიბჭის მოდელს გულისხმობს თითოეული. თუ თქვენი ჩანაწერები მოდელს არ ასახელებს, ჯერ დიზაინი არ გაქვთ.

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

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

ჩამოთვალეთ პრეფიქსების წყვილები და არა აგრეგატები

დაწერეთ მატრიცა. ლოკალური A და B Azure-ის X და Y-მდე ოთხი წყვილია და თითოეულს სჭირდება დაფარვა ან მკაფიო გამორიცხვა. A და B ერთ აგრეგატში გაერთიანება მოიცავს იმასაც, რაც მათ შორისაა და ასე დიზაინი ჩუმად ხვრელს ზრდის.

შეამოწმეთ, რაზეც პირები შეთანხმდნენ და არა ის, რაც შეინახეთ. ASA-ზე ლოკალური და დისტანციური ქსელების სია განზრახვაა; CHILD SA-ები შედეგია.

როცა წყვილი აკლია, გამოსწორება ჩვეულებრივ access-list-ის ხაზი ან სელექტორის ჩანაწერია და არა ახალი გვირაბი.

შეამოწმეთ ბრძანებებით, რომლებიც ობიექტს ასახელებენ

ASA-ზე დაადასტურეთ IKE სესია, შემდეგ IPsec SA-ები, შემდეგ სელექტორის წყვილები. თითოეული ბრძანება სხვადასხვა კითხვას პასუხობს და მხოლოდ პირველის გაშვება აქცევს „გვირაბი აწეულია“ ცრუ დასკვნად. წაიკითხეთ გამოსავალი იმ პირისთვის, რომელიც რეალურად კონფიგურირდით და არა იმ SA-ისთვის, რომელიც სიაში პირველია. Azure-ის მხარე იმავე სამ კითხვას პასუხობს თავისი თვალსაზრისით.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

შემდეგ ჰკითხეთ Azure-ს კავშირის მდგომარეობა az network vpn-connection show --name <connection> --query connectionStatus-ით. „დაკავშირებული“ ნულოვანი ბაიტებით მონაცემთა გზაზე სელექტორის პრობლემაა და არა მარშრუტიზაციის.

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

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

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

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

უკან დაბრუნება და მტკიცებულება, რომ იმუშავა

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

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