Android-ის ერთი VPN-ის წესი არ ბლოკავს ჰოსტინგზე გაშვებულ SSH სერვერს

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

რას ზღუდავს სინამდვილეში ერთი VPN-ის წესი

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

ის არაფერს ამბობს მოსმენად socket-ებზე. SSH სერვერი არ იძახებს VpnService-ს, არ იჭერს პაკეტებს და არ ეჯიბრება იმ ადგილს. ის აკავშირებს პორტს და იღებს კავშირებს, რაც იგივეა, რასაც გააკეთებდა VPN-ის საერთოდ დაყენების გარეშე. ასე რომ, მითი გვირაბის მომწოდებლებზე დაწესებულ ლიმიტს ურევს ქსელურ კავშირებზე დაწესებულ ლიმიტს, და ამ ორს შორის კავშირი არ არის.

მსმენელი დანიშნულების ადგილია და არა გვირაბის ნაწილი

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

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

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

პასუხის გზა ჩვეულებრივ იქ ირღვევა

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

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

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

VPN-ის გვერდის ავლა შემომავალ სერვისს არ არემონტებს

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

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

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

დიაგნოსტიკა ერთი მიმართულებით

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

პორტის შემოწმება გაუშვით პარტნიორიდან და არა ტელეფონიდან, და წაიკითხეთ SSH კლიენტის დეტალური გამონატანი, რომ ნახოთ მარცხდება თუ არა TCP ხელის ჩამორთმევამდე თუ შემდეგ. socket, რომელიც არასოდეს უკავშირდება, და უარყოფილი შესვლა სხვადასხვა ეტაპია სხვადასხვა პასუხისმგებელთან.

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