Android SSH SOCKS პროქსი: რატომ მხოლოდ თქვენი აპების ნახევარი უკავშირდება

თქვენ შედიხართ SSH-ით, ამატებთ -D 1080-ს და ბრძანება წარმატებით სრულდება. ახლა ტელეფონზე SOCKS მსმენელი არსებობს, და აპების ნახევარი მაინც მობილური მონაცემებით გადის გარეთ. ეს ნორმალური შედეგია და არა გატეხილი გვირაბი: ssh -D ქმნის პროქსის საბოლოო წერტილს, და Android აპები პროქსის მხოლოდ მაშინ იყენებენ, როცა რაღაც აიძულებს მათ. ჯაჭვის ეტაპობრივად გავლა გვიჩვენებს, სად ცხოვრობს სამუშაოს ყოველი ნაწილი სინამდვილეში.

დაიწყეთ იქ, სადაც ტრაფიკი იწყება

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

სანამ სხვა რამეს ჩართავთ, დაამტკიცეთ, რომ მსმენელი მუშაობს თავად ტელეფონის shell-იდან კლიენტით, რომელიც პირდაპირ SOCKS-ს ლაპარაკობს:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

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

დაამატეთ ის ნაწილი, რომელიც Android-ს სჭირდება

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

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

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

შეინახეთ SSH ტრანსპორტი დაჭერის გარეთ

თავად SSH კავშირი არ უნდა დაბრუნდეს იმ SOCKS გვირაბში, რომელსაც ინარჩუნებს. თუ ადაპტერი SSH აპის ტრაფიკს იჭერს, გვირაბი დამოკიდებულია კავშირზე, რომელიც გვირაბს ელოდება, და შედეგი ციკლია, რომელიც ჩერდება ან ვარდება ადაპტერის გაშვებისთანავე.

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

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

მიჰყევით DNS-სა და UDP-ს ჯაჭვის ბოლომდე

OpenSSH-ის დინამიკური გადამისამართება TCP კავშირებს გადააქვს. ეს არ არის UDP-associate ან ICMP ტრანსპორტი, და ადაპტერს არ შეუძლია UDP გადამისამართების გამოგონება UDP პაკეტების მიღებით. ყველაფერი, რაც UDP-ს მოითხოვს, მათ შორის QUIC და WebRTC მედია, ან ვარდება ან TCP-ზე ბრუნდება აპის მიხედვით.

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

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

შეამოწმეთ ორი სიცოცხლე და გადაწყვიტეთ

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

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

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