Android VPN სერვერი: root ტელეფონს ხელმისაწვდომს არ ხდის
სამი ცალკეული პრობლემა წყვეტს, შეუძლია თუ არა ტელეფონს VPN კლიენტების მომსახურება: შემომავალი გზა, პრივილეგიების მოდელი და გადაგზავნა. root მხოლოდ შუას ეხება.
root ცვლის, რომელ ქსელურ ოპერაციებს შეიძლება პროცესმა სცადოს. ის ტელეფონს საჯაროდ ხელმისაწვდომ მისამართს არ აძლევს, ოპერატორთან შემომავალ ასახვას არ ინახავს და გადატვირთვის შემდეგ დემონს ცოცხლად არ ინარჩუნებს. თუ წყვეტთ, შეუძლია თუ არა Android ტელეფონს VPN სერვერად მუშაობა, გამოყავით სამი კითხვა: შეუძლია თუ არა განკუთვნილ კლიენტს მსმენელამდე საერთოდ მიღწევა, რა პრივილეგიების მოდელი სჭირდება სერვერის იმპლემენტაციას და რა უნდა გადაიგზავნოს, როცა გვირაბი უკვე აწეულია.
ვინ და საიდან უნდა მიაღწიოს ტელეფონს
კლიენტი იმავე დაშვებულ LAN-ში და კლიენტი მობილურ მონაცემებზე ორ განსხვავებულ ქსელს ამოწმებენ. ჯერ გადაწყვიტეთ განკუთვნილი, რადგან პასუხები ერთმანეთზე არ გადადის. Wi-Fi-ზე მოუთხოვნელი შემომავალი ტრეფიკი ჩვეულებრივ საჭიროებს ასახვას ზედა როუტერზე და მის მიღმა გამოსაყენებელ საჯარო გზას. ფიჭურ ქსელში ოპერატორის დონის NAT ნიშნავს, რომ შემომავალი IPv4 ხშირად მიუწვდომელია, რაც არ უნდა დაუშვას ტელეფონმა.
სწორედ ეს უკანასკნელი წერტილია, რასაც root ვერ შეეხება. ტელეფონის ლოკალური firewall-ი და ოპერატორის NAT სხვადასხვა სისტემებია და პირველის შეცვლა მეორეზე გავლენას არ ახდენს. პირადი ინტერფეისის მისამართი, მობილური მონაცემების ხატულა ან მოსმენითი socket ხელმისაწვდომობის მტკიცებულება არ არის. თუ ოპერატორის გზა მაინც გლობალურად მარშრუტიზებად IPv6-ს გთავაზობთ, მისთვის მაინც გჭირდებათ მიზანმიმართული მსმენელისა და firewall-ის პოლიტიკა; მისამართის ქონა არ არის იგივე, რაც კავშირების მიღება.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
მომსახურება და გადაგზავნა ორი სხვადასხვა წარმატებაა
დასრულებული VPN ხელის ჩამორთმევა ამტკიცებს, რომ გვირაბი არსებობს. ის არ ამტკიცებს, რომ კლიენტს შეუძლია ტელეფონის უკან მდებარე LAN-ზე მიღწევა, და არ ამტკიცებს, რომ ტელეფონს შეუძლია ინტერნეტის გასასვლელად მუშაობა. ეს ცალკეული კონფიგურაციებია, რომლებიც აგებულია შიდა მისამართების გეგმაზე, მარშრუტებზე, დაბრუნების ქცევასა და თქვენ მიერ რეალურად სასურველი ამოცანისთვის ვიწროდ შემოფარგლულ გადაგზავნის პოლიტიკაზე.
მარცხის რეჟიმი პროგნოზირებადია: ხელის ჩამორთმევა წარმატებულია, კლიენტი აჩვენებს დაკავშირებას, და არაფერი იტვირთება. სანამ კლიენტს გამართავთ, გადაწყვიტეთ, ორი როლიდან რომელს აშენებთ. ტელეფონის ქსელში არსებულ მოწყობილობაზე დისტანციური წვდომა და სრული გვირაბით ინტერნეტ გასასვლელი სხვადასხვა გადაგზავნის წესს მოითხოვს, და ორივეს მიცემა, როცა ერთი გინდოდათ, აფართოებს ზემოქმედებას თქვენი მოთხოვნილი შესაძლებლობის დამატების გარეშე.
პრივილეგიების მოდელი არჩევანია, არა root ან არაფერი
ჩვეულებრივ OpenVPN დემონს, რომელიც ბირთვის TUN მოწყობილობას იყენებს, სჭირდება შესაბამისი შესაძლებლობები, წვდომა მოწყობილობის კვანძზე და Android-ის უსაფრთხოების პოლიტიკის თანამშრომლობა. root არ არის SELinux-ისგან საერთო გამონაკლისი; პრივილეგირებული პროცესი მაინც შემოიფარგლება პლატფორმის პოლიტიკით. ამიტომ Linux სერვერზე მშვიდად მომუშავე ბინარს შეიძლება ტელეფონზე ჩავარდეს ნებართვებზე გასაგები შეცდომის გარეშე.
მომხმარებლის სივრცეში gateway-ის იმპლემენტაციას შეიძლება სულ სხვა პრივილეგიების მოდელი ჰქონდეს, ამიტომ გავრცელებული მტკიცება, რომ Android-ზე ყველა VPN სერვერს root სჭირდება, ზედმეტად ფართოა. root გაძლევთ მეტი ოპერაციის სცდის შესაძლებლობას, და არა გარანტიას, რომ ისინი დაიშვება ან შედეგი ხელმისაწვდომი იქნება.
Android-ის საკუთარი VPN სერვისის რეგისტრაცია კიდევ ერთი ცალკე მექანიზმია. ის აპს აძლევს მართულ კლიენტურ ინტერფეისს განსაზღვრული სასიცოცხლო ციკლით; ეს არ არის ზოგადი სერვერის ინსტალატორი, და ტერმინალიდან დემონის გაშვება მას არ აძლევს მუდმივ მართვას, აპლიკაციაზე დამოკიდებულ პოლიტიკას ან საკუთარ აღდგენის გზას.
თუ გასასვლელი წერტილი გინდათ, შეცვალეთ არქიტექტურა
როცა მიზანი უბრალოდ ტელეფონის გავლით დისტანციური ინტერნეტ გასასვლელია და არა არსებულ OpenVPN პროფილთან თავსებადობა, უფრო შესაფერისია მხარდაჭერილი გასასვლელი კვანძი overlay ქსელში. Tailscale ადოკუმენტებს Android გასასვლელი კვანძის როლს საკუთარი რეგისტრაციის, ავტორიზაციისა და კლიენტის არჩევის ნაბიჯებით.
გაცვლა რეალურია და ღირს პირდაპირ თქმა: თქვენ იღებთ სხვა პროტოკოლს, სხვა ნდობის მოდელს და დამოკიდებულებას იმ ანგარიშსა და კოორდინაციის სერვისზე. ეს არ აიძულებს უცვლელ OpenVPN კლიენტს overlay ქსელს შეუერთდეს და არ გაძლევთ OpenVPN მსმენელს საჯარო მისამართზე.
რა სჭირდება ჯერ კიდევ განლაგებას
რომელ გზასაც აირჩევთ, ოპერაციული საფუძვლები წყვეტს, გაუძლებს თუ არა ერთ კვირას. შეინახეთ სერვერის სერტიფიკატები კონფიდენციალურად, გასცეთ განსხვავებული კლიენტური იდენტობები და დაგეგმეთ გაუქმება მანამ, სანამ დაგჭირდებათ. გადაწყვიტეთ, როგორ მოდის განახლებები, რა ინახავს სერვისს ფონზე მომუშავეს და როგორ აღდგება ის გადატვირთვის ან ქსელის ცვლილების შემდეგ.
მოერიდეთ მოხერხებულად მოჩვენებულ მოკლე გზებს: მოძველებული სტატიკური ბინარი, ხისტად ჩაწერილი ინტერფეისის სახელები და გაშვების სკრიპტი, რომელიც არსებულ firewall პოლიტიკას შლის. შემდეგ შედეგი მიიღეთ მხოლოდ კონკრეტული ტესტით: ავტორიზებული დისტანციური კლიენტი აღწევს განკუთვნილ რესურსამდე, აკრძალული დანიშნულებები მიუწვდომელი რჩება, და მოწყობილობა თავისით ბრუნდება მხარდაჭერილი სასიცოცხლო ციკლის მოვლენის შემდეგ. root წვდომა ამ შედეგის ერთ-ერთი შესაძლო შემადგენელია და იშვიათად გადამწყვეტი.