Android always-on VPN: როგორ იხსნება პირველად endpoint-ის სახელი
Android ტრაფიკს ბლოკავს გვირაბის არსებობამდე, მაგრამ კლიენტმა მაინც უნდა ამოხსნას საკუთარი endpoint-ის სახელი. აი რიგი და ის ადგილი, სადაც ჩიხი იქმნება.
ტელეფონი გადატვირთულია, always-on ჩართულია, «VPN-ის გარეშე კავშირების ბლოკირება» აქტიურია და გვირაბი მაინც არ ამოდის. არაფერია არასწორად კონფიგურირებული: ბლოკირება თავის საქმეს აკეთებს და კლიენტის საკუთარი მცდელობა endpoint-ამდე მისასვლელად სწორედ ამ ბლოკირებას ექვემდებარება. Endpoint-ის სახელი უნდა გაიხსნას გვირაბის არსებობამდე, იმ კლიენტის მიერ, რომელსაც ქსელთან საუბარი ნებადართული აქვს, მაშინ როცა ყველა სხვა აპლიკაციას არა. იმის გაგება, რომელი კომპონენტი აკეთებს ამას და რა რიგით, ზუსტად აქცევს ამ საიდუმლოს კონფიგურაციის საკითხად.
რას ითხოვს სინამდვილეში VPN-ის ამწყობი
Android VPN აპლიკაცია პლატფორმას არ გადასცემს სერვერის მისამართს. ის აშენებს ლოკალურ ინტერფეისს: გვირაბის მისამართებსა და მარშრუტებს, რეზოლვერებს, რომლებიც აპლიკაციებმა მის შიგნით უნდა გამოიყენონ, შემდეგ კი establish() აბრუნებს ფაილის დესკრიპტორს, რომელსაც აპლიკაცია კითხულობს და წერს როგორც ნედლ IP პაკეტებს. დისტანციური endpoint ამ ამწყობში საერთოდ არ ჩნდება.
ეს არის მთავარი სტრუქტურული ფაქტი. პლატფორმა ქმნის tun ინტერფეისს და მასზე პოლიტიკას ახორციელებს; აპლიკაცია ტრანსპორტს მომხმარებლის სივრცეში ახორციელებს, რაც ნიშნავს, რომ აპლიკაცია თავად ხსნის თავისი endpoint-ის სახელს და ხსნის დაშიფრულ კავშირს. ამიტომ endpoint ჰოსტის სახელის სახით შესაძლებელია — არა იმიტომ, რომ პლატფორმა სახელებს მხარს უჭერს, არამედ იმიტომ, რომ პლატფორმა endpoint-ს არასდროს ხედავს.
ამწყობის ერთი ველი მაინც იღებს მისამართებს: DNS სერვერები. ისინი უნდა იყოს რეზოლვერების რიცხვითი მისამართები, ჩვეულებრივ ისინი, რომელთა გამოკითხვაც ოპერატორს გვირაბის გავლით სურს. ეს ველი აღწერს, სად აგზავნიან აპლიკაციები მოთხოვნებს გვირაბის ამოტანის შემდეგ. ის არაფერს ამბობს იმაზე, თუ როგორ პოულობს კლიენტი endpoint-ს და სწორედ ამ ორი პარამეტრის გაიგივებიდან იწყება დაბნეულობა.
ორი DNS კითხვა, არა ერთი
პირველი კითხვა: სად აგზავნიან აპლიკაციები მოთხოვნებს, როცა გვირაბი უკვე ამოტანილია? პასუხია რეზოლვერის მისამართი გვირაბის შიგნით, ხელმისაწვდომი tun ინტერფეისის გავლით და კონსტრუქციით რიცხვითი.
მეორე კითხვა: როგორ პოულობს კლიენტი საკუთარ endpoint-ს მანამ, სანამ ეს გვირაბი არსებობს? ეს ძიება ხდება გვირაბის გარეთ, ქვედა დონის ქსელში, კლიენტის პროცესში. მას შეუძლია გამოიყენოს სახელი და უნდა გამოიყენოს რეზოლვერი, რომელიც მოწყობილობისთვის VPN-ის გარეშე ხელმისაწვდომია.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
სამი ეტაპი, სამი განსხვავებული სიმპტომი. ერთი შეცდომის შეტყობინება, რომელიც ამბობს «დაკავშირება ვერ ხერხდება», აერთიანებს მათ, და ამიტომ ადამიანები იწყებენ DNS სერვერის ველის რედაქტირებას იმ პრობლემის გამოსასწორებლად, რომელიც ჯერ კიდევ იმ ველის წაკითხვამდე ხდება.
რატომ შეიძლება bootstrap ჩიხში მოხვდეს
Always-on ჩართული ბლოკირებით ნიშნავს, რომ VPN-ის გარეთ არსებული ტრაფიკი იშლება, მათ შორის იმ აპლიკაციის ტრაფიკი, რომელსაც VPN ეკუთვნის. გასასვლელი ცხადია: აპლიკაცია იძახებს protect()-ს სოკეტზე, რაც აკავშირებს მას ქვედა დონის ქსელთან, ამიტომ ის გვირაბს გვერდს უვლის და გარეთ გაშვება ნებადართულია. ყველა VPN კლიენტმა ეს უნდა გააკეთოს საკუთარი ტრანსპორტისთვის, თორემ სერვერს ვერასდროს მიაღწევს.
ახლა განვიხილოთ განლაგება, სადაც ერთადერთი რეზოლვერი, რომელმაც იცის endpoint-ის სახელი, თავად გვირაბის შიგნითაა. კლიენტს გვირაბი სჭირდება სახელის გასახსნელად და სახელი გვირაბის ასაშენებლად. ეს ნამდვილი ციკლური დამოკიდებულებაა და ვერც ერთი კლიენტის კონფიგურაცია ვერ ხსნის მას. ეს დიზაინის შეცდომაა, არა ბაგი.
დრო იმავე დამოკიდებულებას უფრო რბილი ფორმებით ავლენს. ჩატვირთვისას, პირველ განბლოკვამდე, მოწყობილობას შეიძლება ჯერ არ ჰქონდეს გამოსადეგი ქსელი; captive portal-ზე ქსელი არსებობს, მაგრამ ყველაფერს ბლოკავს პორტალის გარდა; Wi-Fi-დან მობილურ ქსელზე გადასვლისას დაცული სოკეტის ქვედა ქსელი იცვლება და კლიენტმა ეს უნდა შეამჩნიოს და თავიდან გახსნას სახელი. თითოეული მათგანი bootstrap მოვლენაა და თითოეული ღირს განზრახ ტესტირებად, ვიდრე ღამის 3 საათზე აღმოჩენად.
რატომ არ არის პასუხის დაფიქსირება გადაწყვეტა
მაცდური შემოვლითი გზაა სახელის ერთხელ გახსნა და მიღებული მისამართის რიცხვით ველში ჩასმა, ან მისი ხისტად ჩაწერა მორგებულ ბილდში. ეს თითქოს მუშაობს და სახელს სნეპშოტად აქცევს. როცა ოპერატორი გადააადგილებს endpoint-ს — მიგრაცია, anycast-ის ცვლილება, ახალი რეგიონალური მისამართი — კლიენტი კვლავ ძველს ურეკავს და ინტერფეისში არაფერი ხსნის რატომ.
DNS ჩანაწერებს სიცოცხლის ვადა სწორედ იმიტომ აქვს, რომ პასუხები შეიძლება შეიცვალოს; ქეშირება განისაზღვრება ამ ვადით და არა სამუდამოდ. პასუხის დაფიქსირება აგდებს იმ მექანიზმს, რომელიც სახელს მისამართზე უკეთესს ხდის, და ამავდროულად ინარჩუნებს სახელის გამოყენების ოპერაციულ ხარჯს.
დაფიქსირებას ჩვეულებრივ მეორე ცუდი ჩვევაც მოსდევს: იდენტობის შემოწმების შესუსტება, რადგან კავშირი ახლა სხვანაირად ფუჭდება. სერვერის იდენტობის შემოწმება bootstrap პრობლემის ნაწილი არ არის და მისი შესუსტება DNS-ის უხერხულობას უცვლის ჩარევის რისკს.
დიზაინი, რომელიც გადატვირთვას უძლებს
გამძლე გადაწყვეტა არაფრით შთამბეჭდავი არ არის. გამოიყენეთ კლიენტი, რომელიც სწორად ახორციელებს დაცულ სოკეტებს და თავის endpoint-ს ქვედა დონის ქსელში ხსნის, და მიეცით endpoint-ის სახელი, რომელიც საჯაროდ იხსნება ან გვირაბამდე ხელმისაწვდომი რეზოლვერის გავლით. დატოვეთ ბლოკირება ჩართული; მისი სრულად გამორთვა DNS-ის მუშაობისთვის ართმევს იმ თვისებას, რომლისთვისაც განლაგება არსებობს.
იქ, სადაც endpoint უნდა დარჩეს კერძო, უზრუნველყავით პლატფორმისთვის გამოსაყენებელი მკაფიო bootstrap გზა — გვირაბის გარეშე ხელმისაწვდომი რეზოლვერი ან ოპერატორის მიერ შენახული მართვის კავშირი — და შეინახეთ ეს გამონაკლისი ვიწროდ და პოლიტიკის კუთვნილად, არა მომხმარებლის გადამრთველის. Android VpnService-ის დოკუმენტაცია არის ცნობარი იმისა, რას იძლევა პლატფორმა გარანტიად დაცვასა და სასიცოცხლო ციკლზე, და VpnService.Builder-ის ცნობარი ადასტურებს, რომ DNS ველი იღებს რიცხვით მისამართებს.
შემდეგ გადაამოწმეთ სამი ეტაპი, რიგით, გადატვირთვის შემდეგ ახალ კავშირზე: endpoint-ის სახელი იხსნება, გვირაბი მყარდება და პარტნიორი ავთენტიფიცირდება, ხოლო კერძო სახელი იხსნება გვირაბის რეზოლვერის გავლით. თუ პირველი ეტაპი ფუჭდება, შემდგომი ვერაფერი იმუშავებს და შესწორება bootstrap გზას ეკუთვნის — არასდროს რეზოლვერის ველს.
- Endpoint-ის გახსნა ხდება აპლიკაციაში, გვირაბის გარეთ, დაცულ სოკეტზე.
- ამწყობის DNS ველი გვირაბის შიგნით მყოფი აპლიკაციებისთვისაა და არა კლიენტის საკუთარი endpoint-ისთვის.
- რეზოლვერი, რომელიც მხოლოდ გვირაბის გავლითაა ხელმისაწვდომი, ჩიხია და არა ნელი გაშვება.
- ტესტეთ endpoint, ავთენტიფიკაცია და კერძო ძიება ცალ-ცალკე გადატვირთვის შემდეგ.