SSH დისტანციურ ASA-ზე საიტის VPN-ით: ნაბიჯ-ნაბიჯ

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

აირჩიეთ მისამართი, რომელსაც ნამდვილად მართავთ

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

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

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

management-access ინტერფეისზე სპეციფიკურია

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

აქ ორი გამონაკლისი მოქმედებს. მხოლოდ მართვისთვის განკუთვნილი ინტერფეისები ამ მექანიზმის გარეთ არის, და ASA 9.20-ის მართვის სახელმძღვანელო აღნიშნავს, რომ ნაგულისხმევი CiscoSSH სტეკი არ უჭერს მხარს ინტერფეისებს შორის SSH-ს VPN-ით, მაშინ როცა ASA SSH სტეკი უჭერს. დაადასტურეთ აქტიური სტეკი გაშვებულ ვერსიაზე, სანამ მარშრუტებზე დროს დახარჯავთ.

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

კლიენტსა და მომხმარებლის სახელის მოთხოვნას შორის ოთხი დამოუკიდებელი კარიბჭე დგას: მარშრუტისა და გვირაბის შესაბამისობა მართვის წყვილისთვის, ინტერფეისის ACL, რომელიც ნებას რთავს TCP 22-ს ASA-ს მისამართზე, ssh ნებართვა, რომელიც ფარავს ადმინისტრატორის წყაროს, და AAA აუთენტიფიკაცია ამ მომხმარებლისთვის. თითოეულ მათგანს შეუძლია პაკეტის ჩამოგდება კლიენტისთვის იმის თქმის გარეშე, თუ რომელი კარიბჭე დაიკეტა.

სანამ რამეს შეცვლით, გამოიყენეთ packet-tracer, რომ ნახოთ რომელი კარიბჭე ფარდება: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. კვალი ასახელებს ACL-ს, NAT ეტაპს და to-the-box გადაწყვეტილებას, რაც ჩვეულებრივ საკმარისია მარშრუტიზაციის პრობლემის დაშვების პრობლემისგან გასაყოფად.

დაწერეთ ვიწრო ნებართვა და არა ფართო

შეზღუდეთ ნებართვა დამტკიცებული ადმინისტრაციული ქვექსელით და იმ ინტერფეისით, რომელიც იღებს გვირაბის ტრაფიკს: ssh 10.10.5.0 255.255.255.0 inside. დააკავშირეთ იგი აუთენტიფიკაციის მეთოდს, მაგალითად aaa authentication ssh console LOCAL-ს, და დასახელებულ ლოკალურ ანგარიშს, ნაცვლად იმისა, რომ გარე ინტერფეისზე ყველა წყარო გახსნათ.

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

შეამოწმეთ დასახელებული ჰოსტიდან, შემდეგ კვლავ შევიწროვეთ

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

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