Android-ის OpenVPN გვირაბის მისამართის გარეშე მარშრუტს არ ამატებს

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

წაიკითხეთ წარუმატებლობა იმ თანმიმდევრობით, რომლითაც კლიენტი ასრულებს მას

Android-ის VpnService.Builder ორ ცნებას ცალკე ინახავს: addAddress() მისამართს ათავსებს იმ ინტერფეისზე, რომელსაც აპი აშენებს, addRoute() ამატებს დანიშნულების პრეფიქსს, და establish() უარს ამბობს ინტერფეისის შექმნაზე, სანამ მინიმუმ ერთი მისამართი არ დაემატება. OpenVPN კლიენტი პროფილს და სერვერის მიერ გამოგზავნილ ოფციებს ზუსტად ამ გამოძახებებზე ასახავს, ამიტომ კავშირი, რომელიც არასდროს აანალიზებს მისამართს, ინტერფეისს საერთოდ ვერ ააშენებს.

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

შემოწმება 1: აყენებს სერვერი მისამართს პასუხში?

მარშრუტიზებული OpenVPN სერვისისთვის მისამართი მოდის სერვერის აუზიდან ან თითო კლიენტის გამოყოფიდან, და ტოპოლოგია განსაზღვრავს მის ფორმას. OpenVPN 2.4 ან უფრო ახალ სერვერზე ქვექსელური ტოპოლოგიის სერვისი ასე გამოიყურება:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

ამ ფორმით სერვერი აგზავნის რაღაცას, როგორიცაა ifconfig 10.8.0.6 255.255.255.0. ძველი topology net30 ინსტალაცია ნაცვლად პარტნიორის მისამართს აგზავნის, მაგალითად ifconfig 10.8.0.6 10.8.0.5, ამიტომ ორ მოდელს შორის გადატანილი პროფილი შეიძლება სწორად გამოიყურებოდეს, სანამ არასწორ ქსელურ ნიღაბს ატარებს.

კლიენტის კავშირის ჟურნალში მოძებნეთ გამოგზავნილი ოფციების ნაკრები. თუ მასში საერთოდ არ არის ifconfig სტრიქონი, სერვერს მისამართი არასდროს გამოუგზავნია ან კლიენტმა ოფცია უარყო. სერვერზე, რომელიც იყენებს client-config-dir-ს, სერტიფიკატის common name-ის მიხედვით დასახელებული ფაილი უნდა არსებობდეს და შეიცავდეს გამოყოფას:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

შემოწმება 2: ინახავს კლიენტი მიღებულ მისამართს?

ზედმეტად ფართო ფილტრი მეორე გავრცელებული მიზეზია. pull-filter არსებობს OpenVPN 2.4 და უფრო ახალში, და როცა რამდენიმე ფილტრი ერთსა და იმავე ოფციას ემთხვევა, იმარჯვებს ბოლო დამთხვეული, ამიტომ ბოლოში დატოვებული catch-all მისამართს შეცდომის გარეშე შლის:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

შეავიწროვეთ ფილტრი იმ ოფციამდე, რომლისგანაც ნამდვილად გსურთ თავის დაღწევა, და მისამართი ხელუხლებლად დატოვეთ:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

ყველა pull-ის გამორთვის რჩევა ჩვეულებრივ მოდის მისგან, ვისაც ერთი მარშრუტის მოშორება სურს. route-nopull უფრო ვიწრო გადამრთველია: ის ინახავს ifconfig-ს და სხვა გამოგზავნილ ოფციებს, ხოლო უარყოფს გამოგზავნილ მარშრუტებს და DHCP-ის ტიპის ოფციებს. გამოიყენეთ ის, როცა ეს ნამდვილად გსურთ, და მისამართის საკითხს ცალკე უპასუხეთ.

შემოწმება 3: თქვენი საწერია მისამართი?

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

მარშრუტში დისტანციური LAN-ის პრეფიქსი დანიშნულებაა და არასდროს ტელეფონის იდენტობა. 10.60.0.0/24-ის მარშრუტი ამბობს, რომ ამ ქსელს გვირაბით მიაღწიოთ; ის არაფერს ამბობს იმაზე, რომელი 10.60.0.x მისამართი უნდა ჰქონდეს ტელეფონს, და ტელეფონს არცერთი არ უნდა ჰქონდეს. სტატიკური გამოყოფები სერვერის მხარეს ეკუთვნის, სადაც დინამიკურ აუზს ვერ დაეჯახება.

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

შემოწმება 4: სხვა რამ იკავებს გვირაბის ადგილს?

Android ერთდროულად მხოლოდ ერთ აქტიურ VPN სერვისს უშვებს. სხვა VPN აპს, ან მუდამ ჩართული VPN-ის ჩანაწერს, რომელიც ჩართული დარჩა უკვე უმოქმედო პროფილისთვის, შეუძლია დაიკავოს ეს ადგილი სანამ თქვენი OpenVPN კლიენტი გამოიძახებს establish()-ს. მაშინ ინტერფეისი არასდროს არ ჩნდება, მიუხედავად იმისა, რომ პროფილი ვალიდურია, ამიტომ გათიშეთ სხვა VPN, გამორთეთ მუდამ ჩართვის პარამეტრი და ხელახლა დაუკავშირდით სანამ პროფილს შეეხებით.

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

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