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

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

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

დაამტკიცეთ, რომ მარშრუტი არ არსებობს და არა უბრალოდ გატეხილია

დაიწყეთ იმის დამტკიცებით, რომ მარშრუტი არ არსებობს და არა გატეხილია. Linux-ზე ip route show dev tun0 ჩამოთვლის, რა დააყენა კლიენტმა გვირაბის მოწყობილობაზე. Windows-ზე route print ან Get-NetRoute იმავეს აჩვენებს ცხრილის ფორმით.

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

დრო: დამატება შესრულდა მოწყობილობის არსებობამდე

კლიენტი აანალიზებს სერვერის PUSH_REPLY-ს მას შემდეგ, რაც საკონტროლო არხი აწეულია და მას შემდეგ, რაც მან ინტერფეისი დააკონფიგურა. მხოლოდ მაშინ ეხება ის მარშრუტიზაციის ცხრილს, იმ მექანიზმით, რომელსაც პლატფორმა გვთავაზობს. Linux გადის netlink-ზე; Windows იყენებს API-ს, რომელიც მოითხოვს ამაღლებულ ტოკენს. სკრიპტი ან კლიენტი, რომელიც მარშრუტებს კონფიგურაციის წაკითხვისთანავე ამატებს, შეიძლება გაეშვას TUN/TAP მოწყობილობის არსებობამდე, და ბირთვი უარყოფს დამატებას.

იგივე შეჯიბრი ხსნის, რატომ მუშაობს ხელით აკრეფილი მარშრუტი, ხოლო ავტომატური არა: სანამ მას აკრეფთ, ინტერფეისი უკვე აწეულია.

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

უფლებები: ვის შეუძლია ცხრილის შეცვლა

Windows-ის მარშრუტიზაციის ცხრილის შეცვლას სჭირდება ამაღლებული ტოკენი. ჩვეულებრივი მომხმარებლის მიერ გაშვებულ GUI-ს შეუძლია ადაპტერის მისამართი სერვისის მეშვეობით დააყენოს და მაინც ვერ შეძლოს მარშრუტის დამატება. მაშინ ჟურნალი აჩვენებს წვდომა უარყოფილი ტიპის შეცდომას და არა დაკარგულ გაგზავნას.

GUI-ის ადმინისტრატორად გაშვება, ან სერვისზე დაფუძნებული კლიენტის გამოყენება, ცვლის ამ შედეგს. დაგეგმილი დავალება, რომელიც კლიენტს საჭირო ტოკენის გარეშე იწყებს, არ ცვლის.

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

პოლიტიკა: გაგზავნილი მარშრუტები შეიძლება განზრახ გადააგდოთ

route-nopull აიძულებს კლიენტს უგულებელყოს სერვერის მიერ გაგზავნილი მარშრუტები, მათ შორის გაგზავნილი ნაგულისხმევი მარშრუტი, მაშინ როცა გვირაბის მისამართი კვლავ მიიღება. გაგზავნილი DNS და DHCP პარამეტრები იმავე მითითებით გადაიგდება. ასეთი კლიენტი ხარვეზიანი არ არის; ის საკუთარ კონფიგურაციაში მკაფიო მარშრუტის სტრიქონებს ელოდება.

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

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

შეადარეთ გაგზავნის სია ცხრილს

დაკავშირების შემდეგ სერვერის გაგზავნის სია დადეთ კლიენტის ცხრილის გვერდით. Linux-ზე ეს არის ip route show dev tun0; Windows-ზე route print ან Get-NetRoute. თუ მარშრუტი არ არსებობს, ჯერ დააყენეთ სწორად. თუ ის არსებობს და ტრაფიკი ვერ გადის, გადადით გადაცემისა და ბანდის პოლიტიკაზე.

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