OpenVPN TUN და TAP: სამი პირობა, რომელიც წყვეტს

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

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

რას გადააქვს სინამდვილეში თითოეული ინტერფეისი

TUN მოწყობილობა layer-3 წერტილ-წერტილის ინტერფეისია: ბირთვი მას IP პაკეტებს აძლევს და ტუნელი მათ პარტნიორის მისამართამდე მიჰყავს. TAP მოწყობილობა layer-2 ინტერფეისია, რომელიც Ethernet კადრებს გადააქვს, და სწორედ ეს ხდის ხიდს საერთოდ შესაძლებელს, როგორც ბირთვის დოკუმენტაცია აღწერს. არცერთი მათგანი არ ცვლის, როგორ შიფრდება დატვირთვა, და არცერთი სიძლიერის პარამეტრი არ არის. არჩევანი ეხება იმას, რა უნდა გაცვალოს ბოლოებმა და არა იმას, რამდენად კარგად არის დაცული ტრაფიკი.

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

პირველი პირობა: სჭირდება რამეს მეორე დონე?

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

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

მეორე პირობა: შეუძლიათ კლიენტებს?

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

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

მესამე პირობა: ნამდვილად ინტერფეისის საკითხია?

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

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

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

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