რატომ ASA-ის დისტანციური მომხმარებელი ქვექსელს აღწევს, აპლიკაციას კი არა
მარშრუტები ამტკიცებს, რომ გვირაბი მუშაობს, და არა ის, რომ მომხმარებელს აპლიკაციის გახსნა შეუძლია. წაიკითხეთ სესიის მიერ მიღებული ფილტრი, შემდეგ შეამოწმეთ დაშვებული და უარყოფილი კავშირი.
თქვენი მომხმარებელი უკავშირდება, იღებს მისამართს, აკეთებს პინგს აპლიკაციის ქვექსელში მდებარე სერვერზე და მაინც ვერ ხსნის მასზე არსებულ სერვისს. ეს კომბინაცია ASA-ზე ნორმალურია, რადგან წარმატებული გვირაბი და გამოსაყენებელი ნებართვა სხვადასხვა პარამეტრით განისაზღვრება. გაყოფილი გვირაბის სია ირჩევდა, რომელი დანიშნულებები შევიდნენ გვირაბში; VPN ფილტრი და თავად დანიშნულების წვდომის წესები განსაზღვრავს, რას შეიძლება მიაღწიოს გაშიფრულმა მოთხოვნამ. სამივე გადაწყვეტილება რიგით გაიარეთ და ნუ გააფართოებთ მარშრუტების სიას, სანამ რამე შეიცვლება.
სამი გადაწყვეტილება, რომელთა არევაც ადვილია
დაშვება პასუხობს, შეუძლია თუ არა მომხმარებელს საერთოდ გვირაბის აწყობა: მონაცემები, სერტიფიკატი და ნებისმიერი მეორე ფაქტორი. მარშრუტის არჩევა პასუხობს, რომელ დანიშნულებებს აგზავნის კლიენტი ამ გვირაბში. ავტორიზაცია პასუხობს, შეუძლია თუ არა გაშიფრულ მოთხოვნას სერვისამდე მისვლა. მხოლოდ მესამე ქმნის იმ შეცდომას, რომელსაც მომხმარებელი იუწყება.
მათი გარჩევის სწრაფი გზაა იკითხოთ, რას გატეხავს ცვლილება. მარშრუტის ამოღება გაყოფილი სიიდან აჩერებს ტრაფიკს ამ ქვექსელისკენ, თუმცა არაფერს აძლევს; VPN ფილტრში ACE-ის დამატება დანიშნულებას აძლევს იმის შეცვლის გარეშე, რასაც კლიენტი გვირაბში ატარებს.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
წაიკითხეთ ფილტრი, რომელიც სესიამ რეალურად მიიღო
დაიწყეთ ცოცხალი სესიიდან და არა იმ კონფიგურაციიდან, რომელიც გგონიათ, რომ მოქმედებს. show vpn-sessiondb detail anyconnect ბეჭდავს მინიჭებულ ჯგუფურ პოლიტიკას და ამ სესიაზე მიმაგრებული ფილტრის სახელს. თუ ველი ცარიელია, არც ერთი ფილტრი არაფერს ავალდებულებს და ბლოკირება სხვა ადგილიდან მოდის.
შემდეგ წაიკითხეთ პოლიტიკა, რომელსაც ეკუთვნის მნიშვნელობა, ნაგულისხმევი მნიშვნელობების ჩათვლით, რადგან ფილტრი შეიძლება მემკვიდრეობით იყოს მიღებული და არა დაწერილი იქ, სადაც უყურებთ:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
შეადარეთ სესიაზე არსებული ფილტრის სახელი ACL-ს, რომელიც ახლახან შეასწორეთ. მსგავსი სახელის ACL, რომელიც მომხმარებელს არასდროს მიუღია, ვერ შეცვლის ამ სესიის რესურსების პოლიტიკას და ეს არის ყველაზე გავრცელებული მიზეზი, რატომაც სწორად მოჩვენებულ ცვლილებას ეფექტი არ აქვს.
პრიორიტეტი ხსნის დანარჩენს. ფილტრის პარამეტრისთვის DAP ჩანაწერი აღემატება მომხმარებლის სახელის ატრიბუტებს, ხოლო მომხმარებლის სახელის ატრიბუტები აღემატება ჯგუფურ პოლიტიკას. როცა სესია გიჩვენებთ მოულოდნელ ფილტრს, ჯგუფზე შეხებამდე მოძებნეთ ამ მომხმარებლის შესატყვისი DAP პოლიტიკა.
გაყოფილი სია და ფილტრი ცალკე ველებია
ASA 9.x-ზე ჯგუფური პოლიტიკა ინახავს split-tunnel-network-list და vpn-filter როგორც სხვადასხვა პარამეტრს, და 9.22 ჯგუფური პოლიტიკის სახელმძღვანელო სწორედ ამიტომ აღწერს მათ ცალ-ცალკე. ქსელის სია მარშრუტიზაციის მინიშნებაა კლიენტისთვის; ფილტრი წვდომის კონტროლის სიაა, რომელიც გაშიფრულ ტრაფიკზე ვრცელდება.
ეს განსხვავება მნიშვნელოვანია, როცა მომხმარებელს ქვექსელში ერთი HTTPS სერვისი სჭირდება. ჩასვით ქვექსელი გაყოფილ სიაში, რომ პაკეტები გვირაბში შევიდეს, შემდეგ ფილტრში მხოლოდ ის სერვისი დაუშვით. მარშრუტების სიის გაფართოება არაფერს ანიჭებს უფლებას, ხოლო მისი შემცირება აღსრულების მექანიზმი არ არის.
შეამოწმეთ, საერთოდ თუ არის ინტერფეისის ACL გზაზე
გაშიფრული დისტანციური წვდომის ტრაფიკი ყოველთვის არ გადის გარე ინტერფეისის ACL-ში ისე, როგორც ადამიანები ვარაუდობენ. სადაც sysopt connection permit-vpn ჩართულია, ASA იყენებს თავის დოკუმენტირებულ VPN გვერდის ავლას ამ ტრაფიკისთვის, ხოლო შესაბამისი VPN ფილტრები შემდეგც მოქმედებს. პარამეტრი შეამოწმეთ show run all sysopt ით და ნუ დაასკვნით ტოპოლოგიის დიაგრამიდან.
ნებისმიერ შემთხვევაში, დანიშნულების ჰოსტის საკუთარი ფაირვოლი და აპლიკაციის ავტორიზაცია გზაზე რჩება. ASA-ის წესი, რომელიც TCP 443-ს უშვებს, აპლიკაციას მომხმარებლის მიღებას არ აიძულებს.
მიიღეთ ცვლილება უარყოფილი კავშირითაც
მხოლოდ დაშვებული ტესტი ძალიან ცოტას ამტკიცებს, რადგან მომუშავე გვირაბი ერთსა და იმავე პირველ პაკეტს წარმოქმნის, ფილტრი იქნება თუ არა. გახსენით მიზნობრივი სერვისი კლიენტიდან, შემდეგ სცადეთ დანიშნულება, რომელიც დახურული უნდა დარჩეს, და დაადასტურეთ, რომ ის სწორი მიზეზით ვერ ხერხდება.
ბილეთის დახურვისას ჩაწერეთ ოთხი ფაქტი: მიღებული იდენტობა, პოლიტიკა და ფილტრი, რომლებიც სესიამ რეალურად მიიღო, გაყოფილ სიაში არსებული დანიშნულებები და რესურსი, რომლის მიღწევაც მომხმარებელს ნებადართული ჰქონდა. ეს ოთხი ხსნის, სად კონტროლდება ტრაფიკი მარშრუტების სიის ფაირვოლად გადაქცევის გარეშე.
თუ სერვისი კვლავ უარყოფს ფილტრის ნებართვის შემდეგ, გადადით ჰოსტზე: მოსმენის მისამართი, ჰოსტის ფაირვოლი და აპლიკაციის საკუთარი მომხმარებლების დაკავშირება. გვირაბმა ამ მომენტში თავისი საქმე გააკეთა და ASA-ზე შემდგომი ცვლილებები მხოლოდ რისკს უმატებს.