სად უნდა იყოს მარშრუტი OpenVPN-ში: კლიენტთან თუ სერვერთან?
სერვერის კონფიგურაციაში შიშველი მარშრუტი ცვლის სერვერს და არა კლიენტს. აირჩიეთ კლიენტის ფაილი, გლობალური push ან ერთი კლიენტის push და შეამოწმეთ რა მოვიდა.
თქვენ ამატებთ route 10.60.0.0 255.255.255.0 სერვერის კონფიგურაციას, გადატვირთავთ, ხელახლა აერთებთ ლეპტოპს და ქვექსელი კვლავ მიუწვდომელია იმ ლეპტოპიდან. ხაზი მიღებულია, სერვისი სუფთად გაეშვა და ჟურნალში არაფერი არ ჩანს არასწორად. მოხდა ის, რომ მარშრუტი დაყენდა იმ მანქანაზე, რომელიც თქვენ შეცვალეთ: კარიბჭე ახლა ფიქრობს, რომ შეუძლია ამ პრეფიქსს მიაღწიოს, ხოლო კლიენტს არაფერი უთქვამთ. განლაგება მთელი კითხვაა და არსებობს ოთხი ადგილი, სადაც იგივე ხაზი შეიძლება ცხოვრობდეს.
ოთხი ადგილი და ვინ იღებს თითოეულს
მარშრუტი შეიძლება დაემატოს თავად კლიენტის კონფიგურაციით, შესთავაზოს ყველა კლიენტს გლობალური push-ით, შესთავაზოს ერთ კლიენტს კლიენტისთვის სპეციფიკური ფაილით, ან ჩაიწეროს სერვერის საკუთარ მარშრუტიზაციის კონტექსტში.
ეს ოთხი შემთხვევა იყენებს თითქმის იდენტურ სინტაქსს და იძლევა სრულიად განსხვავებულ შედეგებს. პირველი სამი გავლენას ახდენს იმაზე, თუ რას აგზავნის კლიენტი გვირაბში; მეოთხე გავლენას ახდენს იმაზე, თუ როგორ აღწევს სერვერი ქსელს, რაც სასარგებლოა, როცა თავად სერვერს გზა სჭირდება და საზიანოა, როცა მას განაწილებად აღიქვამენ.
გადაწყვიტეთ, რომელი ოთხიდან გსურთ, სანამ ხაზს დაწერთ, შემდეგ დაადასტურეთ მიმღები.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
რატომ აკვირვებს შიშველი სერვერის მარშრუტი ხალხს
სერვერის კონფიგურაცია პირველი ადგილია, სადაც ადმინისტრატორები იხედებიან, და იქ მყოფი მარშრუტის დირექტივა ისე იკითხება, როგორც განცხადება VPN ქსელზე. ასე არ არის. OpenVPN მას განიხილავს როგორც ლოკალური მარშრუტის დაყენებას იმ მანქანაზე, სადაც დემონი მუშაობს, რაც ზუსტად იმ ტიპის ცვლილებაა, რასაც ip route-ით გააკეთებდით და შემდეგ დაივიწყებდით.
განაწილება მოითხოვს, რომ მარშრუტი push-ით გაიგზავნოს, ხოლო push მოითხოვს, რომ კლიენტმა ის ჩამოწიოს. კლიენტი, რომელიც გაშვებულია ჩამოწერილი ოფციების გამორთვით, სრულიად უგულებელყოფს შეთავაზებას. სერვერის ფაილის გადაწერამდე შეამოწმეთ ამ ხელის ჩამორთმევის ორივე ბოლო, რადგან სერვერის ჟურნალი არ იწუწუნებს: მისი მხრიდან შეთავაზება გაგზავნილია. მიღებული მარშრუტი ასევე ამოქმედდება მხოლოდ შემდეგ კავშირზე და არასდროს სესიაში, რომელშიც უკვე იმყოფებით.
როგორც კი ორ მოქმედებას ცალ-ცალკე დაინახავთ, წარუმატებლობა წყვეტს იდუმალურობას: სერვერი აღწევს პრეფიქსს, კლიენტი ვერ ახერხებს და ორივე განაცხადი ერთდროულად ჭეშმარიტია.
კლიენტისთვის სპეციფიკური ფაილები და იდენტობა, რომელსაც ისინი ემთხვევა
კლიენტისთვის სპეციფიკური ფაილი იწოდება იმ იდენტობით, რომელიც სერვერმა დაადასტურა, რაც ნაგულისხმევად სერტიფიკატის საერთო სახელია. სამუშაო მაგიდის კლიენტში მეგობრული კავშირის სახელი არ არის ეს მნიშვნელობა და შეუთანხმებლობა ქმნის ფაილს, რომელიც არასდროს იკითხება.
შეამოწმეთ დირექტორია, რომელსაც სერვერი რეალურად იყენებს, შემდეგ დაადასტურეთ, რომ ფაილის სახელი ზუსტად ემთხვევა დადასტურებულ იდენტობას, დიდი და პატარა ასოების ჩათვლით.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/იმ ფაილის შიგნით მარშრუტი მაინც უნდა გაიგზავნოს push-ით, რადგან კლიენტისთვის სპეციფიკური კონტექსტი არის ოფციების ერთობლიობა, რომელიც გამოიყენება იმ კლიენტის სესიაზე და არა ლოკალური მარშრუტიზაციის ცხრილი. იქ შიშველ მარშრუტს იგივე პრობლემა აქვს, რაც გლობალურ ფაილში შიშველ მარშრუტს.
კლიენტის საკუთარი ფაილი და ინსტრუმენტი, რომელიც მას ფლობს
კლიენტის კონფიგურაციაში მოთავსებული მარშრუტი დაყენდება, როცა ეს კლიენტი დაუკავშირდება, და წაიშლება, როცა გათიშდება, რაც სწორი სასიცოცხლო ციკლია სტატიკური დანიშნულებისთვის.
თუ პროფილს ქსელის მენეჯერი ფლობს, მან შეიძლება ერთხელ შემოიტანოს ეს ოფციები და შემდეგ შეინახოს საკუთარი ასლი. ჩამოტვირთული ფაილის შემდგომი რედაქტირება არაფერს ცვლის, რაც გავრცელებული მიზეზია ფრაზისა "მარშრუტი არსებობს, მაგრამ არ მოქმედებს".
შეამოწმეთ აქტიური პროფილი და არა ჩამოტვირთული ფაილი, და შეამოწმეთ იმპორტირებული პარამეტრები, რომლებსაც მენეჯერი აჩვენებს. შემდეგ დაუკავშირდით და ჰკითხეთ სისტემას, რომელ გზას იყენებს კონკრეტული მისამართი, იმის ნაცვლად, რომ ჩათვალოთ, რომ გვირაბმა მოიგო, რადგან მარშრუტი ტექსტურ ფაილში არსებობდა.
შეამოწმეთ კლიენტზე, შემდეგ შეამოწმეთ დაბრუნების გზა
ჰკითხეთ კლიენტის საკუთარ მარშრუტიზაციის ცხრილს დანიშნულების შესახებ და არა სერვერისას. პრეფიქსის შიგნით ერთი ჰოსტის ძიება საკმარისია იმის საჩვენებლად, თუ რომელი ინტერფეისი და შემდეგი ნახტომი იქნება გამოყენებული.
ip route get 10.60.0.10თუ ძიება გვირაბზე მიუთითებს, განაწილებამ იმუშავა და დარჩენილი პრობლემა სხვაგანაა. თუ ის ნაგულისხმევ კარიბჭეზე მიუთითებს, მარშრუტი არ დაყენებულა, გაფილტრდა კლიენტის მხარის ოფციით, ან ეკუთვნის პროფილს, რომელსაც კლიენტი არ იყენებს.
დავუშვათ, განაწილებამ იმუშავა და მაინც არაფერი პასუხობს: მაშინ შეამოწმეთ გადაგზავნა კარიბჭეზე, მოპირდაპირე მხარის დაბრუნების მარშრუტი და მათ შორის ნებისმიერი ფაირვოლი. მარშრუტი ირჩევს გზას, ის არ იძლევა წვდომას.