Access Server-ის კარიბღის მომხმარებელი: კლიენტის ფილიალის LAN-ის მარშრუტიზაცია

შეგიძლიათ გააკეთოთ ping OpenVPN კლიენტის გვირაბის მისამართზე და მაინც ვერ მიაღწეთ არცერთ ჰოსტს მის უკან არსებულ LAN-ში. Access Server აძლევს კლიენტს მისამართს VPN აუზიდან, და აუზის მისამართი არის ყველაფერი, რაც სერვერმა იცის, რომ საკუთარია. ფილიალის პრეფიქსი ცალკე ფაქტია, რომელიც უნდა გამოცხადდეს, და ამის შემდეგაც ფილიალს სწირდება გადამცემი, ხოლო ცენტრალურ ოფისს — დაბრუნების გზა. არასწორ ადგილაში ჩაწერილი მარშრუტი გადაწყვეტას ჰგავს და არაფერს არ ცვლის.

ორი მისამართი, საკუთრების ორი განსხვავებული პრეტენზია

როცა კლიენტი უკავშირდება, Access Server ანიჭებს მას მისამართს კონფიგურირებული VPN აუზიდან, მაგალითად 10.90.0.0/24. ეს მინიჭება ერთი ჰოსტის იჯარაა. კავშირში არაფერი ამბობს, რომ იგივე კლიენტი დგას ასევე 10.60.0.0/24-ის წინ, და სერვერი არ გამოიცნობს: LAN პრეფიქსი ხელმისაწვდომია კონკრეტული კლიენტის გავლით მხოლოდ მაშინ, როცა ადმინისტრატორი გამოაცხადებს.

ამიტომ სტატიკური მარშრუტი სხვა მანქანაზე არ მუშაობს. მარშრუტი ამბობს, გაგზავნე 10.60.0.0/24 ამ მისამართზე, მაგრამ თუ მისამართი ეკუთვნის კლიენტს, რომელიც არასდროს მონიშნულა კარიბღედ, სერვერს არ აქვს მიზეზი ეს პაკეტები იქ მიატანოს, და კლიენტის სტეკმა შეიძლება ისინი გადააგდოს. გამოცხადება და მარშრუტი ერთი მექანიზმის ორი ნახევარია.

რას ამონტაჟებს სინამდვლეში კარიბღის პარამეტრი

Admin Web UI-ში გამოცხადება მომხმარებლის თვისებაა: ჩართეთ Configure VPN gateway კონექტორის მომხმარებელზე და შეიყვანეთ ფილიალის რეალური პრეფიქსი Network on the VPN client side-ში. ეს მომხმარებელი ავთენტიფიცირდება როგორც ყველა სხვა, ამიტომ მას სწირდება უმეთველმთველო მოწყობილობისთვის შესაბამისი სერტიფიკატების პოლიტიკა, და მისი ავტომატური შესვლის პროფილი საიდუმლოა, არა კომფორტის ფაილი.

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

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

დაასრულეთ ორივე ქსელის დაბრუნების გზები

კონკრეტული გეგმა: ცენტრალური ოფისი 10.40.0.0/24, ფილიალი 10.60.0.0/24, VPN აუზი 10.90.0.0/24, და Access Server ხელმისაწვდომია კერძო მისამართზე ცენტრალური ოფისის მხრიდან. ცენტრალური ოფისის როუტერს სწირდება მარშრუტები ფილიალის პრეფიქსისთვის და აუზისთვის, ორივე Access Server-ისკენ. მათგან გარეშე გვირაბი ატარებს მოთხოვნას და პასუხი გადის ნაგულისხმევი კარიბღით, რაც იძლევა კლასიკურ ნახევრადღია კავშირს.

ფილიალში კონექტორმა უნდა გადასცეს პაკეტები, რომელბიც მას არ არის მიმართული: IP გადაცემა მის ოპერაციულ სისტემაში და გვირაბისა და LAN-ის ინტერფეისებზე შეზღუდული გადაცემის ნებართვა; Linux-ზე ეს არის net.ipv4.ip_forward=1 forward ჯამის წესებთან ერთად, Windows-ზე — routing and remote access. შემდეგ ფილიალის ჰოსტებს სწირდება დაბრუნების გზა: ან კონექტორი მათი ნაგულისხმევი კარიბღეა, ან არსებული კარიბღე ატარებს სპეციფიკურ მარშრუტებს ცენტრალური ოფისისა და აუზის პრეფიქსებისთვის.

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

წაიკითეთ წარუმატებლობა როგორც გზა, და არა როგორც ნებართვა

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

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

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

Access Server-ის site-to-site გაკვეთილი იმავე პარამეტრებს პროდუქტის რიგით ჩამოთვლის; ღირს მისი ერთხელ მიყება, სანამ დიზაინს საკუთარ პრეფიქსებს მოარგებთ.