OpenVPN კვლავ ძველ მარშრუტებს აგზავნის? შეამოწმეთ, რა ჩატვირთა

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

ქვემოთ მოცემული შედარება პროცესიდან გარეთ მიდის, რადგან პროცესია ერთადერთი ავტორიტეტი იმაში, რომელი ფაილია ძალაში.

ფაილი, რომელიც თქვენ შეასწორეთ და ფაილი, რომელსაც პროცესი კითხულობს

დაიწყეთ unit-ით და მის მიერ შექმნილი ბრძანების სტრიქონით. systemd ჰოსტზე systemctl cat openvpn@server ბეჭდავს ExecStart სტრიქონს, ხოლო instance unit ჩვეულებრივ კონფიგურაციის გზას instance-ის სახელიდან იღებს, ამიტომ openvpn@office სახელით გაშვებული დემონი სხვა ფაილს კითხულობს, ვიდრე openvpn@server სახელით გაშვებული. შეადარეთ ეს მიმდინარე პროცესის argv-ს. კონფიგურაციის მართვის ხელსაწყო კიდევ ერთ გზას ამატებს ცვლილების დასაკარგად: მას შეუძლია სწორი ფაილი ჩაწეროს იმ ადგილას, რომელსაც unit არასოდეს ახსენებს, და მაშინ წარმატებული განლაგება არაფრის მსგავსი ჩანს.

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

რას აგზავნის სერვერი და რას აყენებს კლიენტი

გაგზავნილმა მარშრუტმა ორი ფილტრი უნდა გაიაროს. სერვერზე ის უნდა იყოს ჩატვირთულ კონფიგურაციაში და არა კომენტარში ჩასმულ ბლოკში ან კლიენტისთვის სპეციფიკურ ფაილში, რომლის სახელი არ ემთხვევა. კლიენტზე pull უნდა იყოს ჩართული და არცერთ pull-filter-ს არ უნდა გადააგდოს ეს პარამეტრი. დაუკავშირდით verbosity 4-ით და წაიკითხეთ გაგზავნილი პარამეტრები, რომლებზეც კლიენტი იტყობინება: თუ მარშრუტი ამ სიაშია, სერვერმა თავისი საქმე გააკეთა და კლიენტი ირჩევს, არ დააინსტალიროს ის.

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

გაგზავნილი პრეფიქსი და დაბრუნების მარშრუტი სხვადასხვა პრობლემაა

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

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

შეადარეთ ცხრილები ორივე ბოლოში

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

სამი იდენტიფიკატორი ერთად შეინახეთ: კონფიგურაციის გზა, unit-ის ან instance-ის სახელი და იმ კლიენტის იდენტობა, რომლითაც გამოსცადეთ.

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

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