ASA FirePOWER მოდულს FMC-მდე მართვის მარშრუტი არ აქვს

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

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

დახაზეთ მოდული ცალკე ჰოსტად

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

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

იპოვეთ, სად იწყვეტა დაბრუნების გზა

ავიღოთ ბირთვით მარშრუტიზებული განლაგება. მოდული FMC-ისკენ მიმართულ ტრაფიკს Layer 3 ბირთვში აგზავნის, ბირთვი დისტანციურ მართვის დანიშნულებას ASA-ის შიდა ინტერფეისისკენ გადასცემს, ხოლო საიტის VPN მეორე მხარეს გადააქვს. შემდეგ დისტანციურ საიტს სჭირდება დაბრუნების მარშრუტი მოდულის მართვის ქვექსელში. ამ ჯაჭვის ყოველი ნაბიჯი შეიძლება სწორი იყოს, სანამ ის ბოლო მარშრუტი აკლია, და ამიტომ ჩავარდნა ასე ხშირად გატეხილ გვირაბს ჰგავს.

სანამ რამეს შეცვლით, წაიკითხეთ თავად ASA-ის ხედვა:

show interface ip brief
show route
show running-config interface

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

შეამოწმეთ, რას თვლის ASA დაკავშირებულად

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

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

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

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

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

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

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

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

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