ახალი ჰოტსპოტის კლიენტის IP-ის მიღებაზე გაჭედვა VPN-ის ხარვეზი არ არის
დაკავშირება, ლოკალური DHCP იჯარა და გადაგზავნა სამი ეტაპია. მისამართის მიღებაზე გაჭედილი მოწყობილობა VPN-ს ვერასოდეს მიუღწევია, ამიტომ შეწყვიტეთ DNS-ის რედაქტირება.
ტელეფონი უერთდება ჰოტსპოტს, რჩება „IP მისამართის მიღებაზე“ და საბოლოოდ ნებდება. ბუნებრივი დასკვნაა, რომ ტელეფონის VPN ხელს უშლის DNS-ს, ამიტომ ადამიანები იწყებენ რეზოლვერებისა და დამატებული წესების რედაქტირებას. ეს არასწორი ეტაპია. კლიენტმა ლოკალური მისამართი არასოდეს მიიღო, და მის გარეშე მას არც კარიბჭე აქვს, არც რეზოლვერი და არც გადასაგზავნი არაფერი, ამიტომ ჰოსტ ტელეფონზე VPN-ის არცერთი პარამეტრი ვერ ხსნის ამ მარცხს. დაკავშირება, ლოკალური მისამართის მინიჭება და გადაგზავნა სამი ცალკე ეტაპია და მხოლოდ უკანასკნელი ეხება გვირაბს.
სამი ეტაპი და რომელზეც ხართ
ჯერ დაკავშირება მოდის: კლიენტი უერთდება ჰოტსპოტის უსადენო ქსელს. არასწორი პაროლი, WPA3-ის შეუსაბამობა ან რადიოს თავსებადობის პრობლემა აქ იშლება და კლიენტი ჩვეულებრივ ამას ამბობს. მეორე მისამართის მინიჭებაა: IPv4-ისთვის კლიენტი იჯარას ითხოვს და იღებს მისამართს ლოკალური კარიბჭის პარამეტრებთან ერთად, ხოლო IPv6 ჩვეულებრივ DHCP-ის ნაცვლად მარშრუტიზატორის გამოცხადებებს იყენებს, როგორც AOSP-ის tethering დოკუმენტაცია აღწერს. მესამე გარე წვდომაა: ჰოსტ ტელეფონი ნებადართულ ტრაფიკს აგზავნის იმ ზედა დინების გზაზე, რომელიც აირჩია, რომელიც შეიძლება იყოს მისი გვირაბი ან არ იყოს.
კლიენტზე არსებული ფორმულირება გეუბნებათ ეტაპს. მისამართის მიღებაზე გაჭედვა მეორე ეტაპია, სანამ რომელიმე პაკეტი ინტერნეტისკენ გავა. დაკავშირებული, მისამართით, მაგრამ არაფერი იტვირთება, მესამე ეტაპია, სადაც მარშრუტიზაცია, სახელები და გვირაბის დაფარვა ყველა მნიშვნელოვანია. მესამე ეტაპის დიაგნოსტირება, როცა კლიენტი მეორეზეა გაჭედილი, ის გზაა, რომლითაც ხუთწუთიანი იჯარის პრობლემა DNS-ის რედაქტირებით სავსე შუადღე ხდება.
მითი: მარშრუტიზებული VPN ლოკალურ DHCP-ს შორეულ მოთხოვნად აქცევს
მარშრუტიზებული გვირაბი IP პაკეტებს მოძრაობს მის მიერ არჩეული დანიშნულებებისთვის. DHCP აღმოჩენა ჰოტსპოტის საკუთარ სეგმენტზე გაშვებული მაუწყებაა და ტელეფონზე არსებული tethering სერვისი მას ლოკალურად პასუხობს, ამიტომ კლიენტს მისამართის მიღება გვირაბის ჩართულობისასაც შეუძლია. მხოლოდ განზრახ ხიდად ქცეული ან რელე გადაცემული კონსტრუქცია აგზავნის ამ გაცვლას სხვაგან და ეს სხვა მარცხის ხელწერის მქონე სხვა განლაგებაა.
ამიტომ „VPN სერვერი DHCP-ს არ პასუხობს“ დიაგნოზი არ არის, მოდელის შეცდომაა. ლოკალური შუამავალი ტელეფონზეა. თუ პასუხს წყვეტს, მიზეზები ლოკალურია: tethering სერვისი, კლიენტების ზღვარი, იჯარის აუზი ან კლიენტი, რომელმაც დაკავშირება არასოდეს სწორად დაასრულა. აქედან არცერთი გვირაბის შორეულ მხარეს არ ცხოვრობს.
რას ამტკიცებს სინამდვილეში მოქმედი არსებული კლიენტი
თუ უკვე დაკავშირებული ლეპტოპი ჯერ კიდევ მუშაობს, ხოლო ახალი ტელეფონი არა, ჰოტსპოტი და ზედა დინების გზა მთლიანობაში ცოცხალია. ეს შედარება სასარგებლოა და ის არ არის მტკიცება იმისა, რომელი კომპონენტია დამნაშავე, რადგან მოქმედმა კლიენტმა შეიძლება უბრალოდ შეინარჩუნოს ცვლილებამდე მიღებული იჯარა და ჩუმად განაახლოს ის.
იქ ყოფნისას ღირს ორი ლოკალური ზღვრის შემოწმება. ჰოტსპოტი სასრულ იჯარის აუზს და კონფიგურირებად კლიენტთა ზღვარს ემსახურება, ამიტომ დაკავშირებულ და ჩაძინებულ მოწყობილობას შეიძლება მისამართი შეინარჩუნოს, სანამ ახალი ელოდება. ხოლო კლიენტი, რომელსაც სხვა ქსელის სტატიკური კონფიგურაცია ახსოვს, იჯარას საერთოდ არ ითხოვს, რაც გარედან ერთნაირად გამოიყურება და კლიენტზე, არა ტელეფონზე სწორდება.
შეინარჩუნეთ შედარება ლოკალური და შექცევადი
მოწყობილობაზე, სადაც პოლიტიკა იძლევა საშუალებას, შეადარეთ ახალი კლიენტის ერთი დაკავშირება გვირაბის გამორთულ და შემდეგ ჩართულ მდგომარეობაში, ჰოტსპოტი და კლიენტი დანარჩენში უცვლელად დატოვეთ. ჩაწერეთ ტელეფონისა და კლიენტის ვერსიები, არჩეული პროფილი და ზუსტად ის ეტაპი, რომელიც ჩავარდა. მართულ ტელეფონზე სუფთა ტესტისთვის სთხოვეთ დამტკიცებული შედარება აღსრულების გამორთვის ნაცვლად.
გვირაბზე დამოკიდებული თანმიმდევრული იჯარის მარცხი სასარგებლო მტკიცებულებაა ლოკალური პოლიტიკის ან იმპლემენტაციათა ურთიერთქმედების შესახებ. ეს არ არის ლიცენზია მოწყობილობაზე ყველა გადაგზავნისა და NAT წესის გასუფთავებისთვის. ის წესები იცავს უკავშირო ტრაფიკს და გადაგზავნის ფართო დაშვება არ ხსნის, რატომ შეწყვიტა ლოკალურმა DHCP სერვისმა პასუხი.
არ დაფაროთ დაკარგული იჯარა გამოცნობილი სტატიკური მისამართით. განზრახ სტატიკური კონფიგურაცია მოითხოვს ნამდვილ ქვექსელს, კარიბჭეს, განაწილების გეგმას და კოლიზიის შემოწმებას. კლიენტის DNS-ის შეცვლა აქედან არაფერს იძლევა და შემდეგ მოწყობილობას იმავე მარცხით ტოვებს.
რას არ ამტკიცებს იჯარა
მისამართის მიღება ლოკალურ ქსელში დაშვებას ამტკიცებს, არა ტელეფონის გვირაბით დაცვას. როცა კლიენტს იჯარა აქვს, ქვედა დინების გზა ცალკე შეაფასეთ: მართლაც გადის კლიენტის ტრაფიკი ტელეფონზე, იხსნება თუ არა ძიებები იქ, სადაც ელით, და ემთხვევა თუ არა გარე მისამართი თქვენს ნაგულისხმევ გასასვლელს? ეს მესამე ეტაპის კითხვებია და საკუთარ ტესტს იმსახურებს, დაკავშირებაში ჩაკეცვის ნაცვლად.
იმუშავეთ ეტაპებზე რიგრიგობით და მარცხი შეწყვეტს გადაადგილებას. მისამართის მიღებაზე გაჭედილი კლიენტი ლოკალური tethering კითხვაა; მისამართიანი, მაგრამ გვერდების გარეშე კლიენტი გადაგზავნის ან სახელების კითხვაა; გვერდებიანი, მაგრამ არასწორი გასასვლელით კლიენტი გვირაბის დაფარვის კითხვაა. მათი ერთმანეთისგან გამიჯვნა გამართვის უდიდესი ნაწილია.