Android-ის VPN ამოხსნის სრულ ჰოსტსახელს, მაგრამ არა მოკლე სახელს

თქვენ აკრეფთfilesტერმინალის ემულატორში და არაფერი ბრუნდება; აკრეფთfiles.corp.exampleდა იგივე სერვერი მაშინვე პასუხობს. VPN-ის ავტორიზაციის მონაცემებში არაფერი შეცვლილა და კერძო DNS სერვერი არასოდეს გამტყდარა. Android-ზე მოკლე იარლიყი და სრული სახელი გამხსნელში სხვადასხვა გზით მიდის, და ამ გზებიდან ერთი დამოკიდებულია პარამეტრზე, რომელიც გვირაბის მფლობელმა უნდა მოგაწოდოთ. თქვენ წინაშე მდგარი გადაწყვეტილება არ არის, რომელი DNS სერვერი შეცვალოთ, არამედ ის, თუ ვინ აკონტროლებს იმ ქსელს, რომელსაც აპი რეალურად იყენებს.

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

ძებნის სუფიქსი და DNS სერვერი ცალკე ველებია

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

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

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

წაიკითხეთ ეფექტური ქსელი, სანამ რამეს შეცვლით

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

მოწყობილობის ტერმინალური გარსი აქ სუსტი მოწმეა, რადგან მისიresolv.confგამხსნელის ერთი ხედვას ასახავს და არა ყოველი აპისას.

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

თუ VPN აპს თქვენ ქმნით, სუფიქსი ამწყობში მიამაგრეთ

როცა თქვენი აპი ინტერფეისსVpnService-ის მეშვეობით ამყარებს,addSearchDomainამისთვის მხარდაჭერილი შემავალია. ის იღებს დომენის სტრიქონს, მაგალითადcorp.example, და ეს სერვერის მისამართის გადაცემის ალტერნატიული გზა არ არის.

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

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

თუ მხოლოდ VPN-ს იყენებთ, ეს თქვენი დასაყენებელი არ არის

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

დესკტოპ პროფილის ხელახლა იმპორტი კვლავ არაფერს ამტკიცებს მობილურ ასახვაზე.

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

როცა სუფიქსი არსებობს და მოკლე სახელები მაინც ვარდება

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

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

სერტიფიკატები ცალკე ხსენებას იმსახურებს. HTTPS-ის ვალიდაცია იყენებს იმ ჰოსტსახელს, რომელიც რეალურად აკრიფეთ, ამიტომ სწორად გაფართოებადი მოკლე სახელი ხელის ჩამორთმევისას მაინც წარადგენსfiles. სერტიფიკატი, რომელიც გაცემულიაfiles.corp.example-ისთვის, არ იქნება მისთვის ვალიდური, და ეს შეცდომა სწორი ქცევაა და არა თქვენი საწყისი DNS პრობლემის სიმპტომი.

რა უნდა გააკეთოთ შემდეგ

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

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