TAP თუ TUN? Android-ის OpenVPN კლიენტები და ხიდური სერვერები
TAP გადააქვს Ethernet-ის კადრები, TUN — IP პაკეტები, ხოლო Android-ის აპლიკაცია მხოლოდ მეორე ტიპს იღებს. შეადარეთ ორივე და შემდეგ გაასწორეთ სერვერის მხარე.
პროფილი, რომელიც ლეპტოპზე მუშაობს, ტელეფონზე ვერ მუშაობს. აშკარა ნაბიჯია კლიენტის კონფიგურაციაში ერთი სიტყვის შეცვლა. ეს სიტყვა არ დაეხმარება, რადგან ორი ბოლო ერთი და იმავე ტიპის ტრაფიკზე არ ლაპარაკობს.
TAP გადააქვს Ethernet-ის კადრები. TUN გადააქვს IP პაკეტები. Android VPN აპლიკაციას გადაეცემა IP ინტერფეისი, რაც ორი განლაგებიდან ერთს შესაძლებელს ხდის და მეორეს — არა, მიუხედავად იმისა, რას ამბობს კონფიგურაცია.
შედარება მოკლეა, მაგრამ ის წყვეტს, შეგიძლიათ ეს ტელეფონზე გაასწოროთ თუ სერვისი უნდა შეცვალოთ.
ორი ტიპის გვირაბი სხვადასხვა დატვირთვით
TAP ინტერფეისი იქცევა როგორც Ethernet ადაპტერი. ის გადააქვს კადრები, ანუ ARP, მაუწყებლობა და ყველაფერი, რასაც LAN IP-ის ქვემოთ გადააქვს. სწორედ ეს ხდის ხიდს შესაძლებელს: გვირაბი აფართოებს მაუწყებლობის დომენს და კლიენტები ისე იქცევიან, თითქოს კომუტატორში არიან ჩართული.
TUN ინტერფეისი გადააქვს მისთვის მიმართული IP პაკეტები. არ არის შესათანხმებელი არხის დონე, არ არის ARP და არ არის მაუწყებლობა. მარშრუტიზაცია წყვეტს, რა შედის გვირაბში, და სერვერის მხარის კონფიგურაცია ხიდის ნაცვლად ქვექსელს იყენებს.
ორივე ბოლო უნდა შეთანხმდეს, ამ ორიდან რომელს აკეთებს. ერთ მხარეს dev tap-ის dev tun-ით შეცვლა სერვისს არ გარდაქმნის; შედეგად მიიღება კლიენტი, რომელიც მარშრუტიზებულ გვირაბს ელოდება, და სერვერი, რომელიც ჯერ კიდევ კადრებს აგზავნის, და ხელის ჩამორთმევა შეიძლება წარმატებით დასრულდეს, სანამ რაიმე გამოსადეგი არ გადის.
რას აძლევს Android რეალურად აპლიკაციას
პლატფორმის VpnService API აძლევს აპლიკაციას ვირტუალურ ინტერფეისს IP პაკეტებისთვის, კონფიგურირებულს მისამართებით, მარშრუტებით და MTU-ით. ამ API-ში Ethernet ადაპტერი არ არის და აპლიკაციას მისი გამოგონების გზა არ აქვს.
ამიტომ OpenVPN Connect Android-ზე ადასტურებს მარშრუტიზებული TUN კავშირების მხარდაჭერას და არა TAP ხიდს. Android-ის ხშირად დასმული კითხვები ამ საზღვრის კლიენტის მხარის განაცხადია და ემთხვევა პლატფორმის API-ს.
Root უფლებების ქსელური ხელსაწყოები, მორგებული firmware ან პროდუქტი, რომელიც გამოკვეთილ თარგმანის ფენას ახორციელებს, სხვა განლაგებებია. ჩვეულებრივი შემთხვევა ის არის, რის ირგვლივაც უნდა დაგეგმოთ: აპლიკაცია, რომელსაც შეუძლია თქვენი ფაილის იმპორტი და ჩვეულებრივი მომხმარებლის როგორც მუშაობა, IP ინტერფეისით და მის ქვემოთ არაფრით.
როგორ გამოიყურება, როცა მაინც ცდილობთ
კავშირი ჩვეულებრივ მყარდება. სწორედ ეს ხდის წარუმატებლობას დამაბნეველს: კლიენტი აცხადებს კავშირს, სერვერის ჟურნალი აჩვენებს პარტნიორს და არც ერთი აპლიკაცია არ მუშაობს.
ტელეფონისთვის მინიჭებულ მისამართზე მიმართული ტრაფიკი არ აღწევს, რადგან სერვერი კადრებს ხიდავს MAC მისამართზე, რომელიც ტელეფონს არასდროს ჰქონია. მაუწყებლობაზე დამოკიდებული აღმოჩენა ცარიელი რჩება. თუ LAN ხიდის გავლით DHCP-ზეა დამოკიდებული, ტელეფონი ამ გზით იჯარას ვერ მიიღებს, და ხიდურ ქვექსელში ხელით მინიჭებული მისამართი მაინც არ ქმნის დაკარგულ ინტერფეისს.
ზოგი კლიენტი უფრო ადრე ვარდება, პროფილის იმპორტისას, როცა ხედავს მოწყობილობის ტიპს, რომლის განხორციელებაც არ შეუძლია. ორივე ქცევა ერთს ნიშნავს და არც ერთი არ სწორდება მარშრუტების დამატებით, DNS-ის შეცვლით ან გვირაბის მისამართების დიაპაზონის გაფართოებით.
რა უნდა შეცვალოს სერვერის მხარემ
გასწორება ეკუთვნის მას, ვინც VPN სერვისს მართავს, და ის ჩვეულებრივ დამატებაა და არა მიგრაცია. გაუშვით მეორე OpenVPN ინსტანცია მარშრუტიზებული მოწყობილობით, საკუთარი კლიენტური ქვექსელით და სერვერის მხარის კონფიგურაციით, რომელიც მისამართებს ანიჭებს და უგზავნის ტელეფონებისთვის საჭირო მარშრუტებს. არსებული ხიდური ინსტანცია აგრძელებს იმ მოწყობილობების მომსახურებას, რომლებსაც ნამდვილად სჭირდებათ Ethernet.
ორი დეტალი ხდის ამას პრაქტიკაში მუშა. LAN-ს სჭირდება დაბრუნების მარშრუტი ახალი კლიენტური ქვექსელისთვის, VPN ჰოსტზე მიმართული, თორემ პასუხები არასდროს დაბრუნდება. და გვირაბის ჰოსტზე ფაირვოლი უნდა აგზავნიდეს გვირაბის ინტერფეისსა და LAN-ს შორის, და ეს არის ის ნაბიჯი, რომელიც ყველაზე ხშირად გამოტოვდება, როცა თავად ჰოსტიდან ტესტი წარმატებულია.
თუ ოპერატორს სერვისის დამატება არ შეუძლია, ალტერნატივა მოწყობილობაა, რომელსაც ხიდში შეერთება შეუძლია, ანუ ლეპტოპი ან როუტერი, რომელიც ტელეფონის სახელით მოქმედებს. ეს საკუთარი მართვის ხარჯის მქონე შემოვლითი გზაა, არა Android კონფიგურაცია.
გადაწყვიტეთ აპლიკაციიდან, არა გვირაბიდან
იკითხეთ, რას უნდა მიაღწიოს ტელეფონმა რეალურად, შემდეგ კი დაიტანეთ რუკაზე. სახელით ან მისამართით მისადგომი ფაილების გაზიარება ან ინტრანეტ საიტი IP მოთხოვნაა, და მარშრუტიზებული გვირაბი აკმაყოფილებს მას, როცა DNS სახელს ხსნის და მარშრუტი არსებობს. ლოკალურ მაუწყებლობის დომენში მოძრავი აღმოჩენის ხელსაწყო IP მოთხოვნა არ არის და მარშრუტიზაციის ვერც ერთი რაოდენობა ვერ შეავსებს.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
ეს ცხრილი ასევე გასაგზავნი მოთხოვნაა. დაასახელეთ აპლიკაცია, მის მიერ გამოყენებული მისამართი ან სახელი და ის, დამოკიდებულია თუ არა აღმოჩენაზე. ოპერატორს შეუძლია იმ აღწერით იმოქმედოს, რაც ვერავინ ვერ გააკეთებს ისეთი ტელეფონით, რომელიც არ უკავშირდება.
დაბოლოს, შეინარჩუნეთ TAP სერვისი მათთვის, ვისაც ის სჭირდება, იმის ნაცვლად რომ ყველა კლიენტს აიძულოთ LAN ადაპტერის მიბაძვა. ორი მკაფიო მიზნის მქონე სერვისი უფრო ადვილი სატარებელია, ვიდრე ერთი, რომელიც ყველასთვის ნახევრად მუშაობს.