რატომ არის OpenVPN კლიენტის უკან არსებული ქვექსელი მიუწვდომელი?
OpenVPN ვერ გამოიცნობს, რომელ კლიენტს ეკუთვნის დისტანციური LAN. iroute ჩანაწერი კლიენტის ფაილში, დაბრუნების მარშრუტი და გადაგზავნა ამ ქვექსელს მისაწვდომს ხდის.
პინგები სერვერის გვირაბის მისამართზე წარმატებით სრულდება, თავად კლიენტის მარშრუტების ცხრილი სწორად გამოიყურება, და ამ კლიენტის უკან არსებული LAN კვლავ მიუწვდომელია. კლიენტის მარშრუტიზაციის ცხრილი სწორად გამოიყურება, სერვერს აქვს გვირაბისკენ მიმართული მარშრუტი, და პაკეტები მაინც ქრება. ეს არის layer-3 გვირაბის კლასიკური სიმპტომი, რომელმაც არ იცის, რომ მისი ერთ-ერთი კლიენტი თავად კარიბჭეა.
tun ინტერფეისს არ აქვს შემდეგი ნახტომი თითო კლიენტზე. ბირთვი ხედავს ერთ ინტერფეისს მრავალი პარტნიორით, ამიტომ გადაწყვეტილება იმის შესახებ, რომელი კლიენტი მიიღებს პაკეტს დისტანციური LAN-ისთვის, უნდა მიღებულ იქნას OpenVPN პროცესის შიგნით. ეს გადაწყვეტილება კონფიგურირდება iroute-ით, და მის გარეშე პაკეტს წასასვლელი არსად აქვს.
სერვერი მარშრუტიზაციას აკეთებს კლიენტის მიხედვით, არა ინტერფეისის
როდესაც სერვერს სჭირდება პაკეტის გაგზავნა კლიენტის გვირაბის მისამართზე, პასუხი ცალსახაა: მისამართი ეკუთვნის იმ კლიენტის სესიას. როდესაც დანიშნულება ამ კლიენტის უკან მთელი ქვექსელია, მისამართი არ ეკუთვნის არავის, ვინც სერვერმა იცის, და ბირთვის მარშრუტი გვირაბისკენ მხოლოდ ამბობს "ამ ინტერფეისიდან", იმის მითითების გარეშე, რომელი პარტნიორი.
OpenVPN ამას წყვეტს შიდა მარშრუტიზაციის ცხრილით, რომელიც დანიშნულების პრეფიქსს კონკრეტულ კლიენტს უკავშირებს. ეს ცხრილი iroute ჩანაწერებისგან იგება, ამიტომ სერვერის ჰოსტზე ჩვეულებრივი მარშრუტი საკმარისი არ არის. ბირთვის მარშრუტი პაკეტს გვირაბის ინტერფეისამდე მიიყვანს; შიდა დაკავშირება წყვეტს, რომელი სესია მიიღებს მას. ამიტომაც შეკეთება არასდროს ჩნდება ბირთვის მარშრუტების გამოსავალში.
თუ დაკავშირება აკლია, პაკეტი სერვერამდე აღწევს, ემთხვევა გვირაბის მარშრუტს და უგულებელყოფილია, რადგან არცერთი კლიენტი არ ითხოვს დანიშნულებას. არაფერი ჩაწერს სუფთა შეცდომას, ამიტომ გაუმართაობა მდუმარე შავ ხვრელს ჰგავს და არა მარშრუტიზაციის მარყუჟს.
iroute ჩანაწერის დაწერა, რომელიც კლიენტს ასახელებს
iroute ცხოვრობს კლიენტისთვის სპეციფიკურ კონფიგურაციის ფაილში, არა სერვერის მთავარ კონფიგურაციაში. მიმართეთ სერვერი დირექტორიაზე client-config-dir ოფციით, შემდეგ შექმენით ფაილი, რომლის სახელია კლიენტის სერტიფიკატის საერთო სახელი, და ჩადეთ მასში პრეფიქსი.
ფილიალისთვის, რომლის LAN არის 10.20.0.0/24 და სერტიფიკატის საერთო სახელია branch-router, ამ გზაზე არსებული ფაილი შეიცავს ხაზს, როგორიცაა iroute 10.20.0.0 255.255.255.0. მთავარ კონფიგურაციას მხოლოდ დირექტორიის ოფცია სჭირდება; პრეფიქსი კლიენტთან ცხოვრობს.
საერთო სახელი მყიფე ნაწილია. სხვა subject-ით გაცემული სერტიფიკატი, ან განლაგება, რომელიც მომხმარებლებს მომხმარებლის სახელით ამოწმებს, მაშინ როცა ფაილი სერტიფიკატის მიხედვით არის დასახელებული, ქმნის ფაილს, რომელიც არასდროს იკითხება. შეამოწმეთ სახელი, რომელსაც სერვერი რეალურად აცნობს სესიისთვის, და გაითვალისწინეთ ოფცია, რომელიც შეუთავსებელ კლიენტს აცდენს ნაცვლად იმისა, რომ ჩუმად დაუკავშირდეს მისი მარშრუტების გარეშე. ფაილის სერტიფიკატთან შესაბამისად გადარქმევა ხუთწუთიანი შესწორებაა, რომელიც ძალიან გრძელ საღამოს თავიდან აიცილებს.
ერთ კლიენტს შეიძლება ჰქონდეს რამდენიმე პრეფიქსი. დაამატეთ ერთი iroute ხაზი თითო ქსელზე და შეინახეთ სია იმ კლიენტის დანარჩენ პარამეტრებთან, რომ დაკავშირება შემოწმებადი დარჩეს.
დაბრუნების გზის აგება ორივე მიმართულებით
პაკეტების დისტანციურ LAN-ამდე მიყვანა საქმის ნახევარია. კლიენტმა ასევე უნდა გაგზავნოს ამ LAN-ის ტრაფიკი გვირაბში, რაც ჩვეულებრივ კეთდება კლიენტისთვის მარშრუტის მიწოლით: ხაზი, როგორიცაა push "route 10.8.0.0 255.255.255.0", ყველა კლიენტს ეუბნება, როგორ მიაღწიოს სერვერის მხარეს არსებულ ქსელს. ფილიალისთვის ეკვივალენტური მარშრუტი გვირაბისკენ მიუთითებს ყველაფერზე, რასაც სერვერის მხარეს უნდა მიაღწიოს.
დაბრუნების მიმართულებას შორეულ მხარეს მფლობელი სჭირდება. იმ მხარეს ვინმემ უნდა იცოდეს უკან გზა: სტატიკური მარშრუტი LAN-ის მარშრუტიზატორზე, რომელიც VPN-ის აუზს სერვერისკენ მიმართავს, ან მისამართების თარგმნა სერვერზე ტრაფიკის LAN-ში შესვლამდე. სტატიკური მარშრუტი ორიგინალურ მისამართებს ჟურნალებსა და წვდომის წესებში ხილულად ტოვებს, მაგრამ LAN-ის მფლობელის თანამშრომლობას მოითხოვს; თარგმნა თვითკმარია, მაგრამ მალავს, ვინ რეალურად დაუკავშირდა.
გადაგზავნა უნდა იყოს ჩართული სერვერის ჰოსტზე. მის გარეშე ბირთვი პაკეტს გვირაბიდან იღებს და უარს ამბობს LAN-ის ინტერფეისზე გადაცემაზე, რაც კლიენტის თვალსაზრისით ზუსტად iroute-ის ნაკლს ჰგავს.
მიწვდომის შემოწმება სწორი ზონდებით
შეამოწმეთ ფენებად, ნაცვლად შორეულ ბოლოზე ping-ისა და გამოცნობისა. სერვერიდან შეამოწმეთ, რომ პრეფიქსის შიდა დაკავშირება არსებობს და ბირთვის მარშრუტი გვირაბისკენ მიუთითებს. კლიენტიდან დაადასტურეთ, რომ მიწოლილი მარშრუტი დაყენებულია და რომ LAN-ის მისამართისთვის მისი ნაგულისხმები გზა გვირაბია.
შემდეგ დააკვირდით პაკეტებს. გვირაბის ინტერფეისზე ჩაწერა გვიჩვენებს, უგზავნის თუ არა სერვერი კლიენტისკენ, და LAN-ის ინტერფეისზე ჩაწერა გვიჩვენებს, გადასცემს თუ არა. თუ პირველი პაკეტებს აჩვენებს, მეორე კი არაფერს, პრობლემა გადაცემაში ან ფილტრშია; თუ არცერთი არაფერს აჩვენებს, ძებნა უფრო ადრე ჩავარდა.
გვირაბით დაკავშირებული ორი სერვერი ორივე მხარეს იმავე წესს იმეორებს: თითოეულს სჭირდება iroute მეორის აუზისთვის, და თითოეულს სჭირდება მარშრუტი და გადაგზავნა, რომლებიც გზას სიმეტრიულს ხდის. მარშრუტიზაცია და პოლიტიკა აქ ცალკე საკითხებია. მარშრუტიზაცია წყვეტს, სად შეიძლება პაკეტი წავიდეს, ხოლო FORWARD წესი წყვეტს, დასაშვებია თუ არა, ამიტომ ორი iroute ხაზის მქონე კლიენტი ორივე პრეფიქსს აღწევს, თუ ფილტრი სხვას არ ამბობს.