Android OpenVPN: პირადი მარშრუტის დამატება ტელეფონის root-ის გარეშე
დაამატეთ ერთი მარშრუტი იმ პროფილში, რომელსაც Android ნამდვილად ტვირთავს, შემდეგ შეამოწმეთ, უშვებს თუ არა მას სერვერი. სახელმძღვანელო რედაქტირებისთვის, ხელახალი დაკავშირებისა და ოთხი შემოწმებისთვის.
გჭირდებათ კიდევ ერთი პირადი ქვექსელი — ვთქვათ 10.60.0.0/24 — რომელიც პროფილში ახლა არ არის. ლეპტოპზე დაამატებდით მარშრუტს და გააგრძელებდით. Android-ზე VPN აპლიკაციაა, tun მოწყობილობა იმ აპლიკაციისაა და root-ის გარეშე სარედაქტირებელი მარშრუტიზაციის ცხრილი არ არსებობს. მარშრუტი მაინც უნდა არსებობდეს, მაგრამ ის პროფილში შედის, რომელსაც კლიენტი ტვირთავს და მუშაობს მხოლოდ მაშინ, როცა მეორე მხარე თანახმაა. აქ არის რედაქტირება, ხელახალი დაკავშირება, სერვერის მხარე და უკუქცევა.
რედაქტირებამდე: რა შეუძლია მარშრუტს და რა არა
მარშრუტი პასუხობს ერთ კითხვას: რომელი ინტერფეისი უნდა ატარებდეს ტრაფიკს ამ დანიშნულებისკენ. ის არაფერს უფლებას აძლევს. თუ ქსელის მფლობელს არ დაუდასტურებია, რომ ამ ტელეფონს შეუძლია ამ ქვექსელამდე მისვლა, სწორი მარშრუტი ქმნის სწორად შესახედავ კონფიგურაციას და ჩუმ ჩამოგდებას კარიბჭეზე, და შემდეგ საათს არასწორი ფაილის რედაქტირებაში გაატარებთ.
ჯერ მიიღეთ ეს შეთანხმება, წერილობით, თუ ქსელს მფლობელი ჰყავს. შემდეგ ჩაიწერეთ, რასაც არ აკეთებთ: ტელეფონს არ აძლევთ მისამართს იმ LAN-ის შიგნით, არ ცვლით სერვერის მსმენელს და არ ირჩევთ საიტს ჰოსტის სახელით. ეს ოთხი განსხვავებული ცვლილებაა და მხოლოდ პირველია თქვენი.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
შეასწორეთ პროფილი, რომელსაც კლიენტი ნამდვილად ტვირთავს
ჩვეულებრივი OpenVPN ოფციის ტექსტის იმპორტის მქონე თავსებადი კლიენტისთვის დამატება ერთი ხაზია:
route 10.60.0.0 255.255.255.0დაამატეთ ის პროფილის სხეულში, სხვა მარშრუტიზაციის დირექტივების გვერდით, ხოლო ოპერატორის endpoint, სერთიფიკატები, გასაღებების დამუშავება და შემოწმების ხაზები ზუსტად ისე დატოვეთ, როგორც იყო. ნუ ჩასვამთ მთელ ძველ მაგალითს ერთი ხაზის სესხებისთვის: შეკუმშვა, აბსოლუტური ფაილის ბილიკები და მოძველებული cipher პარამეტრები მასთან ერთად მოდის და ცალკე გამართვის სესია დაგიჯდებათ.
ის ნაბიჯი, რომელსაც ადამიანები გამოტოვებენ, ფაილის საკუთრებაა. თუ აპლიკაციამ პროფილი იმპორტირებულია, მის მიერ გამოყენებული ასლი აპლიკაციისაა და ჩამოტვირთული ორიგინალის რედაქტირება არაფერს ცვლის. გამოიყენეთ კლიენტის მიერ მხარდაჭერილი რედაქტორი ან ხელახლა იმპორტი გააკეთეთ განახლების გზით და დაადასტურეთ აქტიური პროფილის სახელი, როცა რამდენიმე მსგავსი სახელი არსებობს. ჩაიწერეთ, რომელი შეცვალეთ.
თუ პროფილს უკვე აქვს route-nopull, სერვერიდან არც ერთი მარშრუტი არ დამონტაჟდება და ყველა პრეფიქსი, რომელიც ტელეფონს სჭირდება, ცხადად უნდა იყოს ჩამოთვლილი. ეს ლეგიტიმური დიზაინია, მაგრამ ნიშნავს, რომ გამოტოვებული ხაზი ზუსტად სერვერის უარივით გამოიყურება.
ხელახლა დაუკავშირდით და შეამოწმეთ მოწყობილობაზე
ჯერ გათიშეთ, შემდეგ ხელახლა დაუკავშირდით ზუსტად იმ პროფილს, რომელიც შეასწორეთ, ნაცვლად იმისა, რომ აპლიკაციას ბოლო სესიის აღდგენის უფლება მისცეთ. გახსენით კავშირის ჟურნალი და დაადასტურეთ, რომ კლიენტმა ახალი ხაზი დაამუშავა; მარშრუტიზაციის დირექტივა, რომელსაც ინტერფეისი უგულებელყოფს, არასწორი ასლის რედაქტირების ჩვეულებრივი შედეგია.
გამოსცადეთ დანიშნულება მისამართით და არა სახელით. ცნობილ სერვისის პორტზე TCP შემოწმება უფრო ინფორმატიულია, ვიდრე ping, რადგან ბევრი ჰოსტი პასუხობს ICMP-ს, სანამ სერვისის პორტი გაფილტრულია. თუ მისამართი პასუხობს და სახელი არა, თქვენ გაქვთ resolver-ის საკითხი და არა მარშრუტიზაციის, და შემდეგი ნაწილი თქვენთვის არ არის.
აქ ორი არეალის შემოწმებაც თავსდება. აპლიკაციის მიხედვით VPN ნიშნავს, რომ მისამართის მარშრუტი შეიძლება არსებობდეს, სანამ აპლიკაცია, რომლითაც ამოწმებთ, შეტანილ სიმრავლეს გარეთაა, ამიტომ შეამოწმეთ აპლიკაციით, რომელიც ნამდვილად შიგნითაა. და IPv4 პრეფიქსი არაფერს ამბობს IPv6 გზაზე; თუ სერვისი dual-stack-ია, დაამატეთ შესაბამისი IPv6 მარშრუტი ან მოელოდეთ, რომ კლიენტი იმ გზას ამჯობინებს, რომელიც არ გინდოდათ.
ერთი უარყოფითი შედეგი ადრევე ღირს ამოცნობად: თუ full-tunnel მარშრუტი უკვე ფარავს 0.0.0.0/0-ს, პრეფიქსი არ აკლია და მისი ხელახლა დამატება არაფერს ცვლის. ორმაგი დაფარვა არ ასწორებს სერვერის მხრიდან უარს ან დაკარგულ პასუხს.
დაასრულეთ გზა სერვერზე
სამი რამ უნდა იყოს ჭეშმარიტი ტელეფონის გარეთ. კარიბჭეს სჭირდება მარშრუტი დანიშნულებისკენ და ნებართვა, გადაამისამართოს ტელეფონის წყარო მისკენ. სამიზნემ უნდა მიიღოს ეს წყარო და დააბრუნოს პასუხები კარიბჭის გავლით, თორემ დიზაინს გასასვლელზე განზრახ თარგმანი სჭირდება. OpenVPN-ის სახელმძღვანელოს route ოფცია კლიენტის მხრიდან დირექტივას მოიცავს; გადამისამართება და დაბრუნების მარშრუტიზაცია ცალკე პარამეტრებია ცალკე მანქანებზე.
თუ დანიშნულება კარიბჭის უშუალოდ უკან არ არის, არამედ სხვა VPN კლიენტის უკან, სერვერს სჭირდება iroute იმ პარტნიორის ქვექსელისთვის. ეს დირექტივა სერვერს ეკუთვნის და აღწერს, რომელ კლიენტს აქვს პრეფიქსი; ტელეფონს არ შეუძლია მისი მიწოდება საკუთარი პროფილიდან და კლიენტის მხრიდან არც ერთი რაოდენობის რედაქტირება არ ცვლის მას.
ცხადად შეამოწმეთ დაბრუნების გზა. პასუხი, რომელიც გამოდის ნაგულისხმევი მარშრუტით და არა გვირაბით, ქმნის კლასიკურ ნახევრად ღია სიმპტომს: კავშირი ერთი მიმართულებით მყარდება და არაფერი ბრუნდება. წყაროს თარგმანი კარიბჭეზე ლეგიტიმური შესწორებაა, როცა სამიზნე ვერ ახდენს უკან მარშრუტიზაციას, მაგრამ ეს საკუთარი შედეგების მქონე პოლიტიკის გადაწყვეტილებაა.
უკუქცევა და მიღება
შეინახეთ წინა პროფილი რედაქტირებამდე. თუ ცვლილება აუარესებს მდგომარეობას, აღადგინეთ ეს ასლი იმავე ხელახალი იმპორტის გზით, ხელახლა დაუკავშირდით და დაადასტურეთ, რომ ძველი ქცევა ბრუნდება — ეს ადასტურებს, რომ შეცვალეთ ის, რაც ფიქრობდით, რომ შეცვალეთ. უკუქცევა, რომელიც ძველ მდგომარეობას არ აღადგენს, ნიშნავს, რომ აპლიკაციას მესამე ასლი აქვს, რომელიც ვერ იპოვეთ.
მიიღეთ ცვლილება, როცა ოთხი რამ სრულდება, შემოწმებული ამ რიგით ახალი დაკავშირების შემდეგ: დანიშნულება პასუხობს თავის სერვისის პორტზე, პირადი სახელი წყდება, თუ მოსალოდნელია, HTTPS კვლავ ამოწმებს განზრახ ჰოსტის სახელს და ყველაფერი კვლავ მუშაობს გადატვირთვის ან Wi-Fi-დან მობილურ ქსელზე გადასვლის შემდეგ. ბოლო შემოწმებაა ის, რაც იჭერს მარშრუტს, რომელიც მხოლოდ მანამ არსებობს, სანამ Android გვირაბს ხელახლა დაამყარებს.
- სანამ რამეს შეასწორებთ, დაადასტურეთ, რომ ქსელის მფლობელი დანიშნულებას უშვებს.
- მარშრუტი ჩადეთ იმ პროფილში, რომელსაც კლიენტი ტვირთავს, შემდეგ ხელახლა იმპორტი გააკეთეთ და დაუკავშირდით.
- შეამოწმეთ სერვისის პორტით, აპლიკაციის არეალის შიგნით, სწორი მისამართების ოჯახისთვის.
- შეასწორეთ გადამისამართება, დაბრუნების მარშრუტიზაცია და iroute სერვერზე, არა ტელეფონზე.
- შეინახეთ უკუქცევის ასლი და გადატვირთვის შემდეგ ხელახლა გამოსცადეთ.