ASA-ს DHCP რელე site-to-site VPN-ზე: ნაბიჯ-ნაბიჯ გზამკვლევი

რელე სამ ეტაპად მუშაობს და მხოლოდ შუა ეტაპი კვეთს VPN-ს. კლიენტი გადასცემს broadcast-ს ფილიალის სეგმენტში, ASA ამ broadcast-ს DHCP სერვერისკენ unicast მოთხოვნად აქცევს, და სერვერი პასუხობს რელეს მისამართს და არა კლიენტს. გაიარეთ ეტაპები ამ თანმიმდევრობით და «რელე გატეხილია» შემთხვევების უმეტესობა აკლია პოლიტიკამდე ან არასწორად წაკითხულ setroute ხაზამდე მიდის.

პირველი ეტაპი: ჩართეთ რელე კლიენტისკენ მიმართულ ინტერფეისზე

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

სანამ რამეს შეცვლით, შეამოწმეთ მოქმედი კონფიგურაცია: რომელ ინტერფეისზეა რელე ჩართული, რომელი სერვერის ფორმაა არსებული და დაკავშირებულია თუ არა setroute კლიენტის ინტერფეისთან. თუ ASA სხვა სეგმენტისთვის DHCP სერვერსაც ამუშავებს, გაჩერდით და წაიკითხეთ შეზღუდვების სია; სერვერი და რელე ერთდროულად ვერ ჩაირთვება ერთსა და იმავე მოწყობილობაზე.

რელე საკუთარ კლიენტისკენ მიმართულ მისამართს დებს gateway-ის მისამართის ველში. სწორედ ამ მისამართს უპასუხებს სერვერი, ამიტომ ის უნდა იყოს ხელმისაწვდომი შორეული ადგილიდან გვირაბის გავლით და არა მხოლოდ ლოკალურად.

მეორე ეტაპი: გადაიტანეთ ASA-ის მიერ გენერირებული ტრაფიკი გვირაბში

ეს არის ნაბიჯი, რომელსაც ხალხი გამოტოვებს. პოლიტიკაზე დაფუძნებული site-to-site VPN ჩვეულებრივ ქვექსელებს შორის ტრაფიკისთვის შენდება, ხოლო რელეს მოთხოვნას თავად ASA აგენერირებს. თუ გვირაბის access list და crypto map მხოლოდ ფილიალის ჰოსტიდან სერვერის ქვექსელამდე ნაკადებს ემთხვევა, რელეს პაკეტი შეიძლება გვირაბში საერთოდ არ შევიდეს. შეამოწმეთ access list ორივე მიმართულებით და არა მხოლოდ ფილიალიდან სერვერისკენ ხაზი.

დაადასტურეთ, რომ საინტერესო ტრაფიკი მოიცავს ASA-ის რელეს წყაროს და სერვერის მისამართს, და რომ უკუმიმართულებაც დაშვებულია. VTI-ზე დაფუძნებულ დიზაინში მარშრუტიზაციის გადაწყვეტილება უფრო მარტივია, მაგრამ VTI-ზე რელეს მხარდაჭერა კონკრეტულ გამოშვებაში გამოჩნდა; ASA-ის DHCP გზამკვლევი მიუთითებს 9.14(1)-ზე, ამიტომ შეამოწმეთ image-ი სანამ VTI-ის მაგალითს ძველ მოწყობილობაზე დააკოპირებთ.

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

მესამე ეტაპი: წაიკითხეთ პასუხი და setroute ოფცია

RFC 2131 ამბობს, რომ როცა ეს ველი ნულის ტოლი არ არის, სერვერი თავის პასუხს giaddr-ში მითითებულ მისამართზე აგზავნის. ამიტომ უკანა გზა უნდა მარშრუტდებოდეს რელეს მისამართზე, და გვირაბის პოლიტიკამ უნდა დაუშვას მიმართულება სერვერიდან რელესკენ. თუ მოთხოვნა გაიარა, მაგრამ შეთავაზება არასოდეს ჩამოვიდა, სწორედ აქ უნდა ვეძებოთ.

შემდეგ გამოყავით ორი მსგავსად ჟღერადი რამ. setroute საკვანძო სიტყვა ცვლის ან ამატებს default router-ის ოფციას, რომელსაც ASA კლიენტს აძლევს. ის არ აყენებს მარშრუტს ASA-ზე და არ ქმნის VPN პოლიტიკას. კლიენტს, რომელიც მისამართს იღებს, მაგრამ ვერსად აღწევს, ხშირად setroute ან scope-ის პრობლემა აქვს და არა გვირაბის. გამოსცადეთ სტატიკური gateway-ის გარეშე კლიენტით და დააკვირდით, რომელი default router გამოჩნდება შეთავაზებაში.

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

რას ვამოწმებ სანამ «გამოსწორებულია» ვიტყვი

დაიწყეთ კლიენტიდან და დაიჭირეთ broadcast, შემდეგ დაადასტურეთ, რომ ASA-მ ის გადაამისამართა თავისი მისამართით, როგორც giaddr. შორეულ მხარეს დაადასტურეთ, რომ სერვერმა ეს მოთხოვნა დაინახა და ფილიალის შესაბამისი scope აირჩია. ფილიალში დაბრუნებულებმა დაადასტურეთ, რომ კლიენტმა შეთავაზება მიიღო და თავის gateway-ს აღწევს.

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

ჩაწერეთ სამი ეტაპი ცვლილებების ჟურნალში: კლიენტისკენ მიმართული ინტერფეისი, რელეს ტრაფიკის დამფარავი VPN პოლიტიკა და სერვერის უკანა მარშრუტი giaddr-მდე. სწორედ ეს ჩანაწერი აქცევს შემდეგი ფილიალის აშენებას განმეორებად საქმედ და არა გამართვის სეანსად. ის ასევე ეუბნება შემდეგ ინჟინერს, რომელი ბრძანების გამონატანი შეაგროვოს პირველად.