TUN/TAP: არასწორი არგუმენტი — OpenVPN-ის ჩარჩოების შეუთანხმებლობა

კლიენტი ავთენტიფიკაციას გადის, ჟურნალი ამბობს დაკავშირებულია, და არც ერთი პაკეტი არ კვეთს გვირაბს. სერვერი წყვეტს მცდელობას write to TUN/TAP: Invalid argument (code=22)-ით, რაც დრაივერის გაუმართაობას ჰგავს და ჩვეულებრივ ასე არ არის. მარშრუტიზატორებსა და პატარა Linux სერვერებზე ეს ხაზი ყველაზე ხშირად ნიშნავს, რომ ორი მხარე არ თანხმდება, როგორ უნდა ჩაისხას მონაცემთა პაკეტები ჩარჩოებში, ამიტომ ბირთვი უარყოფს მისთვის გადაცემულ გაშიფრულ ბუფერს. მარშრუტიზაცია ამ მომენტში ჯერ არ შემოწმებულა.

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

გვირაბი ადის და არაფერი გადის მასში

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

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

შეკუმშვა ჩარჩოებაა და არა გამტარუნარიანობა

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

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

გაასწორეთ ორივე ბოლო ან ამოიღეთ ორივედან

ჩამოთვალეთ ყოველი შეკუმშვის დირექტივა: სერვერის ფაილი, ნებისმიერი გაგზავნილი პარამეტრი, კლიენტის სპეციფიკური ფაილები და კლიენტის პროფილი. სერვერზე comp-lzo-ს სჭირდება იგივე სიტყვა კლიენტზე, და adaptive არის ძველი ნაგულისხმევი, რასაც შიშველი პარამეტრი ჩვეულებრივ ნიშნავს ძველ build-ებში. მარშრუტიზატორის GUI გადამრთველი LZO ან შეკუმშვის ეტიკეტით წერს იმავე პარამეტრს, ამიტომ დააყენეთ ის შესაბამისობაში და არა ალგორითმების შერევით. არ ჩათვალოთ, რომ მსგავსი სახელწოდება თავსებადია.

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

შეამოწმეთ გაგზავნა და მოწყობილობის ტიპი

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

ხიდიანი TAP-ის განთავსებას სჭირდება რეალური ხიდი სერვერზე და არა უბრალოდ სხვა მოწყობილობის სახელი. ინტერფეისის tap0-ად გადარქმევა ხიდში დამატების გარეშე ქმნის მოწყობილობას, რომელიც იღებს ჩაწერას და არსად მიდის.

შემდეგ გადაამოწმეთ ერთი კლიენტითა და ერთი დანიშნულებით: გააკეთეთ ping სერვერის გვირაბის მისამართზე, შემდეგ მის LAN-ში არსებულ ჰოსტზე. პირველი ადასტურებს მონაცემთა არხს, ხოლო მეორე გადაცემას.