რომელი კომპონენტი ფლობს სინამდვილეში OpenVPN-ის მარშრუტების ლიმიტს?
მარშრუტების ლიმიტი შეიძლება ეკუთვნოდეს OpenVPN-ის ძრავას, NetworkManager-ის დანამატს ან სერვერს. დაასახელეთ მფლობელი, სანამ პროფილს შეცვლით ან რიცხვს ასწევთ.
პროფილი, რომელსაც ორასი მარშრუტი აქვს, ერთ მანქანაზე მუშაობს და მეორეზე ორმოცს აყენებს. ძრავას, მის გამშვებ ინტეგრაციას და მის მკვებავ სერვერს თითოეულს თავისი სიტყვა აქვს, და თითოეულს შეუძლია სია სხვადასხვა წერტილში გააჩეროს. ხარვეზის ერთ ლიმიტად წაკითხვა არასწორ ფაილამდე მიგიყვანთ. მექანიზმს სამი ეტაპი აქვს, და შეჩერებული ეტაპი თვალსაჩინო კვალს ტოვებს, როცა იცით რა უნდა მოძებნოთ.
სამი ეტაპი, სამი განსხვავებული ლიმიტი
ჯერ ძრავა აანალიზებს პარამეტრს და წყვეტს, ესმის თუ არა ის ამ ვერსიას. შემდეგ ინტეგრაცია აყენებს იმას, რასაც ძრავა აცნობებს, და მის საკუთარ კოდს შეუძლია სია შეზღუდოს ან გადააფორმოს. ბოლოს სერვერი წყვეტს, რამდენ მარშრუტს გაუგზავნის მოცემულ იდენტობას, სანამ რომელიმე კლიენტის ეტაპი რამეს დაინახავს. სამი ეტაპი, სამი ჭერი, და მათგან მხოლოდ ერთია პროფილში არსებული რიცხვი.
ერთი ჭერის აწევა სხვებისთვის არაფერს აკეთებს. უარყოფილ გაგზავნილ მარშრუტს შეიძლება სერვერზე პოლიტიკის გადაწყვეტილება ჰქონდეს საფუძვლად, კლიენტის მიერ გადაწყვეტილი გადაფარვა, ან ინსტალატორის ლიმიტი, რომელმაც ნამეტი გადააგდო. თითოეულ მათგანს განსხვავებული გასწორება აქვს.
გამოყავით სამივე, სანამ რამეს გაზომავთ. პარსერის შეცდომა ტოკენს ასახელებს, ინსტალატორის ლიმიტი მოკლე მარშრუტების ცხრილს ტოვებს, და პოლიტიკის გადაწყვეტილება საერთოდ არაფერს ტოვებს. კვალი გეუბნებათ, რომელი ეტაპი შეამოწმოთ პირველად.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
პარსერი პირველი ლაპარაკობს
უცნობი პარამეტრი ხმამაღლა და ადრე ვარდება, და შეცდომის ტექსტი ტოკენს ასახელებს. ეს ყველაზე ადვილად ამოსაცნობი ეტაპია: შეადარეთ ზუსტი შეტყობინება დაყენებული ძრავის ვერსიას, რადგან ერთ გამოცემაში დამატებული პარამეტრი წინაში უცნობია. უფრო ახალი განლაგებიდან კოპირებული პროფილი ამ შეუთანხმებლობის ჩვეულებრივი წყაროა. პარსერი არასოდეს ჩუმად უგულებელყოფს ინსტრუქციას, რომელსაც არ იცნობს.
მიღებული პარამეტრი შედეგზე არაფერს ამბობს. ანალიზი წარმატებით სრულდება, და სია მაინც შეიძლება ინსტალატორმა შეკვეცოს ან სერვერმა საერთოდ არ შესთავაზოს. სუფთა ანალიზს განაგრძობის ნებართვად უყურეთ და არა მტკიცებულებად.
ვერსიის სტრიქონი ჩაწერეთ იმ ბინარიდან, რომელიც რეალურად გაეშვა, და არა პაკეტების მენეჯერის წარმოდგენიდან იმის შესახებ, თუ რა არის დაყენებული. ეს ორი უფრო ხშირად არ თანხმდება, ვიდრე მოსალოდნელია.
ინსტალატორს საკუთარი ჭერი აქვს
კომპონენტი, რომელიც აქტივაციას ფლობს, შეიძლება NetworkManager-ის დანამატი იყოს და არა ძრავის ბინარი, და მას შეუძლია საკუთარი ლიმიტი დააწესოს, სანამ რომელიმე გვირაბი არსებობს. მის რედაქტორს შეუძლია აჩვენოს ველი, რომელსაც მოქმედი ძრავა არასოდეს კითხულობს, ან წაიკითხოს ველი, რომელსაც რედაქტორი არ აჩვენებს. ორივე სიტუაცია გარედან კლიენტის ხარვეზად გამოიყურება. არც ერთი არ სწორდება პროფილის რედაქტირებით.
დათვალეთ რა ჩამოვიდა და არა რა იყო კონფიგურირებული. ip route show dev tun0 ბრძანება ჩამოთვლის დაყენებულ მარშრუტებს, და ამ რიცხვის გაგზავნილ სიასთან შედარება გადაგდებულ მარშრუტს აშორებს იმ მარშრუტისგან, რომელიც არასოდეს გაგზავნილა. გაგზავნასთან დამთხვევა ეჭვს სერვერს უბრუნებს.
ძრავას ბინარის გარშემო გარსის კოლოფი უფრო დიდი რიცხვის დასაძალად განახლებებს აბინდავს და უკან დაბრუნებას გამოცნობად აქცევს. ის ასევე მალავს ნამდვილ ლიმიტს ყველასგან, ვინც კონფიგურაციას შემდეგ წაიკითხავს.
სერვერი წყვეტს, რა შემოგთავაზეს
თითოეული კლიენტის პოლიტიკას შეუძლია სია შეამციროს გადაცემამდე. კლიენტისთვის სპეციფიკურ ფაილს შეუძლია ერთი იდენტობისთვის მარშრუტები დაამატოს, ან ჯგუფურ პოლიტიკას შეუძლია ისინი გამოტოვოს, და კლიენტი ვერ არჩევს გაფილტრულ მარშრუტს იმ მარშრუტისგან, რომელიც არასოდეს განსაზღვრულა. სწორედ ეს გაურკვევლობა ხდის სერვერის ჩანაწერს მნიშვნელოვანს. მოითხოვეთ ამ იდენტობის ეფექტური გაგზავნის სია და არა შაბლონი.
შეადარეთ სერვერის ჩანაწერი მიღებულ სიას. მათ შორის სხვაობა პოლიტიკის შრეა, და ის ჩვეულებრივ უფრო მცირეა, ვიდრე პროფილი გვაფიქრებინებს.
როცა დიზაინი იძლევა საშუალებას, შეაჯამეთ მომიჯნავე ქსელები და წაშალეთ მოძველებული ჩანაწერები. ნაკლები და უფრო დიდი მარშრუტი მეტ შემთხვევას წყვეტს, ვიდრე უფრო მაღალი ჭერი.
შეცვალეთ რიცხვი სწორ ადგილას
გამოიყენეთ იმ კომპონენტის დოკუმენტურებული პარამეტრი, რომელიც ლიმიტს ნამდვილად ფლობს. თუ ველი დანამატში არ არის, შეამოწმეთ, დანამატი ფუნქციაზე ძველია თუ სხვა ფონი ფლობს მარშრუტებს. შემდეგ არჩეული მნიშვნელობის გვერდით ჩაწერეთ ძრავის, დანამატისა და სერვერის ვერსიები. შემდეგი განახლება კითხვას ისევ ხსნის, და სწორედ ჩანაწერი ხდის მას პასუხის გაცემად შესაძლებელს.
ხელახლა შეამოწმეთ სამიდან რომელიმეს ნებისმიერი განახლების შემდეგ. სწორ ადგილას აწეული ლიმიტი მაინც იძვრება, როცა იცვლება კომპონენტი, რომელიც მას ახორციელებს. ვერსიების ჩანაწერი ერთადერთია, რაც ამ მოძრაობას წინასწარმეტყველებად აქცევს.