შიდა სერვისის გამოქვეყნება ASA საიტიდან-საიტზე VPN-ის გავლით
ხუთი რიგითი შემოწმება შიდა სერვისის ASA საიტიდან-საიტზე VPN-ის გავლით გასახსნელად: დაცული დიაპაზონი, წყაროს მოდელი, ტრანსლაცია, პორტის ფარგლები, პასუხის გზა.
საიტიდან-საიტზე VPN-ის უკან მცხოვრები სერვისის გამოქვეყნება ერთი ამოცანაა ხუთი წარუმატებლობის წერტილით და ისინი ფიქსირებული რიგით ფუჭდება. გვირაბი ადის, ტრანსლაცია ემთხვევა, ფილიალი პასუხობს და პასუხი იმავე გზით ბრუნდება. როცა რომელიმე მათგანი არასწორია, ბრაუზერი იმავეს აჩვენებს: კავშირს, რომელიც ეკიდება ან ახლდება. სია ზემოდან ქვემოთ გაიარეთ და გაჩერდით პირველ შემოწმებაზე, რომელიც ვერ გაივლის.
შემოწმება 1: გვირაბი იცავს წყაროს მისამართს
დაიწყეთ გვირაბით, რომელიც უკვე ატარებს ტრაფიკს, შემდეგ დაადასტურეთ, რომ მისამართი, რომლის გამოქვეყნებასაც აპირებთ, დაცული დიაპაზონის შიგნითაა. ASA-ზე ეს დიაპაზონი მოდის დაშიფვრის ACL-იდან ან VTI-ის მარშრუტებიდან და მან უნდა დაფაროს წყაროს ნამდვილი მისამართი და არა ქვექსელი, რომელსაც ფილიალი მართვისთვის იყენებს. სელექტორი, რომელიც წყაროს გამოტოვებს, გაძლევთ აწეულ გვირაბს და ნაკადს, რომელიც მასში არასდროს შედის.
დაადასტურეთ ეს გვირაბის მთვლელებით და მარშრუტების ცხრილით, სანამ ტრანსლაციას შეეხებით. თუ წყარო ჰაბიდან გვირაბის გავლით მიუწვდომელია, ამ სიაში შემდგომი ვერაფერი გამოასწორებს.
გაჩერდით აქ, თუ დაცული დიაპაზონი და წყაროს მისამართი არ ემთხვევა.
შემოწმება 2: გადაწყვიტეთ რომელ წყაროს დაინახავს ფილიალი
ფილიალი ხედავს ან კლიენტის თავდაპირველ მისამართს ან ტრანსლირებულს, და ეს არჩევანი წყვეტს დაბრუნების გზას. კლიენტის მისამართის შენარჩუნება უფრო სუფთად იკითხება წყაროს ჟურნალებში, მაგრამ მაშინ ფილიალმა საჯარო კლიენტების პასუხები გვირაბით უნდა დააბრუნოს; ჩვეულებრივი ინტერნეტის ნაგულისხმევი მარშრუტი მათ საპირისპირო მიმართულებით აგზავნის და კავშირი ერთი მიმართულებით კვდება. წყაროს იმ მისამართზე ტრანსლირება, რომელსაც ფილიალი უკვე გვირაბით მარშრუტიზებს, ამ მოთხოვნას ხსნის.
ტრანსლაცია ასევე ცვლის, რისი ჩაწერა შეუძლია წყაროს და რასთან შეიძლება დაემთხვეს წყაროზე დაფუძნებული წესები. თუ აპლიკაციას სჭირდება იცოდეს მოთხოვნის უკან მდგარი ადამიანი, ამის ადგილი დამოწმებული უკუპროქსია და არა NAT-ის გადაწყვეტილება.
შემოწმება 3: დაწერეთ ტრანსლაცია რეალური ინტერფეისების მიხედვით
ASA ტრანსლაციის წესებს რიგით აფასებს და აცნობებს რომელი დაემთხვა, ამიტომ წესის შიგნით ინტერფეისების წყვილი მორთულობა არ არის. გარედან შიგნით გზისთვის დაწერილი წესი არ დაემთხვევა ნაკადს, რომლის შესვლა და გასვლა თქვენი ვარაუდებისგან განსხვავდება.
გზას, რომელსაც აშენებთ, ოთხი მონაკვეთი აქვს და ოთხივე უნდა შეთანხმდეს:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.51.100.25 |
ამ ცხრილის დიაპაზონები დროებით მნიშვნელობებად მიიჩნიეთ. მთავარია, რომ ტრანსლაციის შემდეგ ტოპლი იყოს მისამართი, რომელსაც ფილიალი გვირაბით იღებს, და რომ NAT-ის მდგომარეობაში არსებობდეს შებრუნებული ასახვა, რათა პასუხი გასვლისას აღდგეს.
შემოწმება 4: შეზღუდეთ წვდომის წესი გამოქვეყნებულ პორტზე
გამოაქვეყნეთ პორტი და არა ჰოსტი. წესი, რომელიც წყაროს ყველა სერვისზე უშვებს, ერთ გამოქვეყნებულ აპლიკაციას აქცევს გზად ყველაფრისკენ, რასაც წყარო ამუშავებს, მათ შორის იმ მართვის ინტერფეისისკენ, რომელიც განზრახ ინტერნეტის გარეთ შეინახეთ. დაუშვით გამოქვეყნებული პორტი ტრანსლირებული წყაროდან წყარომდე და ადმინისტრაციული სერვისები დატოვეთ მათ მხოლოდ-VPN გზაზე.
ამავე დროს შეამოწმეთ წესების რიგი. ფართო ნებართვა, რომელიც თქვენი კონკრეტული წესის ზემოთ ზის, კონკრეტულ წესს უხილავს ხდის.
შემოწმება 5: გააკვალეთ ერთი მოთხოვნა და მისი პასუხი
არ დაიწყოთ ბრაუზერით, რადგან ბრაუზერი მალავს რომელი მონაკვეთი ჩავარდა. გააკვალეთ ნაკადი ჰაბზე და წაიკითხეთ შედეგი, სანამ რამეს შეცვლით.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lკვალი ასახელებს დამთხვეულ ტრანსლაციას, წვდომის წესს, რომელმაც ნაკადი დაუშვა ან უარყო, და იმას, გადამისამართდა თუ არა პაკეტი გვირაბში. თუ ის აჩვენებს, რომ ნაკადი გამოდის ინტერფეისიდან, რომელსაც არ ელოდით, NAT-ის წესში ინტერფეისების წყვილი არასწორია. თუ უარყოფას აჩვენებს, წესების რიგი არასწორია. თუ ის გვირაბს აღწევს, მაგრამ წყარო არასდროს პასუხობს, პრობლემა ფილიალის დაბრუნების გზაა.
შემდეგ გაგზავნეთ ერთი რეალური მოთხოვნა გარედან და დაადასტურეთ, რომ პასუხი იმავე გვირაბით ბრუნდება. ჩაწერეთ გამოქვეყნებული ჩანაწერი, ტრანსლაცია, დაცული მისამართების წყვილი და დაბრუნების მარშრუტი გამოქვეყნების ჩანაწერად.