Wi-Fi ამბობს დაკავშირებულია, არაფერი იტვირთება: მოძველებული რეზოლვერები Mac-ზე

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

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

„დაკავშირებული“ არის განაცხადი რგოლზე

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

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

გაყავით სახელები პაკეტებისგან

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

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

წაშალეთ ჩამაგრებული სერვერები

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

ძველი ვერსიები იმავე პანელს ერთი დონით ღრმად მალავენ, ღილაკ „დამატებითი“-ს უკან, იდენტური ქცევით და იმავე შედეგით.

წაიკითხეთ მდგომარეობა და არა პანელი

scutil --dns | head -40 ბეჭდავს რეზოლვერებს, რომლებსაც macOS რეალურად იყენებს, დაჯგუფებულს მოცულობის მიხედვით, ხოლო ცნობილი შიდა სახელის სწრაფი nslookup გვიჩვენებს, საერთოდ მოდის თუ არა პასუხი. შეადარეთ ორი გამონატანი: სუფთა პანელი, სადაც ჯერ კიდევ ჩამოთვლილია ძველი სერვერი, ნიშნავს, რომ ეს პარამეტრი სხვა მწერალს ეკუთვნის. ეს სხვა შეცდომაა, სხვა გამოსავლით.

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

ვინ აბრუნებს ჩანაწერებს

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

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

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