რატომ წყვეტს nslookup VPN-ით, ბრაუზერი კი ვერა
nslookup პირდაპირ ერთ სერვერს ეკითხება; ბრაუზერი მიჰყვება ინტერფეისების ამომხსნელებს, NRPT წესებსა და დაშიფრულ DNS-ს. შეადარეთ ეს გზები VPN-ის რედაქტირებამდე.
nslookup აგზავნის მოთხოვნას თქვენს მიერ დასახელებულ სერვერზე და ბეჭდავს პასუხს, ამიტომ მას შეუძლია წარმატება მაშინ, როცა ბრაუზერის ყოველი ჩანართი ვარდება. ბრაუზერი ოპერაციულ სისტემას სთხოვს ამოხსნას, და სისტემა იწონის თითოეული ინტერფეისის ამომხსნელებს, სახელების ამოხსნის პოლიტიკის წესებს და ადაპტერის ქსელურ მდებარეობას. შემდეგ ბრაუზერს შეუძლია დაამატოს საკუთარი დაშიფრული DNS. სამი განსხვავებული გზა, ერთი სიმპტომი, და გვირაბი ჩვეულებრივ არ არის გატეხილი ნაწილი.
ქვემოთ მოცემული შემოწმებები მიჰყვება ამ გზებს სისტემიდან გარეთ. ნუ შეცვლით VPN პროფილს, სანამ არ გაიგებთ, რომელი გზა უპასუხა და რომელი ვარდა.
სამი პოლიტიკა წყვეტს პასუხს
თითოეულ ინტერფეისს აქვს საკუთარი ამომხსნელების სია და ძიების სუფიქსები. VPN ადაპტერი ამატებს სერვერებს, ხოლო ფიზიკური ადაპტერი ინარჩუნებს თავისას, და სისტემას შეუძლია აიღოს ის, რომელიც პირველი უპასუხებს, ამიტომ ძიება შეიძლება მოემსახუროს გვირაბის გარეთ, არავის მიერ არჩეული. სახელების ამოხსნის პოლიტიკის ცხრილის წესებს შეუძლია შერჩეული დომენები გაგზავნოს შერჩეულ სერვერებზე, ასე გამოიხატება ჩვეულებრივ split DNS Windows-ში. და VPN კლიენტს ან კარიბჭეს შეუძლია გაგზავნოს ამომხსნელის მისამართი, რომელიც მხოლოდ კერძო ქსელში არსებობს.
ეს სამი ისე ურთიერთქმედებს, რომ ბრაუზერიდან თვითნებურად გამოიყურება. კერძო მისამართზე გაგზავნილი ამომხსნელი split გვირაბით მარშრუტის გარეშე ყოველ ძიებას აჩერებს და შემდეგ ავარდნილს ხდის. პოლიტიკის წესი, რომელიც ფარავს შიდა სუფიქსს და მიუთითებს გამორთულ სერვერზე, იძლევა იგივე ხილულ შეცდომას, როგორც დაკარგული მარშრუტი. VPN ადაპტერიდან დაკარგული ძიების სუფიქსი მოკლე სახელს აქცევს არასწორი დომენის საჯარო მოთხოვნად. თითოეულ მათგანს განსხვავებული შეკეთება სჭირდება.
რატომ სვამს ბრაუზერი სხვა კითხვას
nslookup თავის მოთხოვნას აგზავნის თავის მიერ არჩეულ სერვერზე და არ მიჰყვება არც სახელთა სივრცის პოლიტიკას, არც ბრაუზერის დაშიფრული DNS პარამეტრს. ამიტომ საჯარო ამომხსნელზე ხელით მოთხოვნა პასუხობს, მაშინ როცა ბრაუზერი იტყობინება, რომ საიტი არ არსებობს. თქვენ ადარებთ ორ პროგრამას, და არა ერთი პროგრამის ორ მდგომარეობას.
მისამართების ოჯახის უპირატესობა ხსნის შეყოვნებას და არა წარუმატებლობას. ბრაუზერი, რომელიც ჯერ IPv6 ჩანაწერებს ითხოვს გვირაბში, რომელიც მხოლოდ IPv4-ს ატარებს, ელოდება ვადის გასვლას, სანამ უკან დაიხევს. Firefox-ს ჰქონდა ასეთი უპირატესობა სწორედ ამისთვის, და მისი გამორთვა დიაგნოსტიკური ნაბიჯია და არა შეკეთება.
წაიკითხეთ ამომხსნელების სია და წესები
Windows-ში დაბეჭდეთ ის, რაც სისტემას აქვს, სანამ თეორიებს ააგებთ. Get-DnsClientServerAddress აჩვენებს სერვერებს ინტერფეისების მიხედვით, Get-DnsClientNrptRule ჩამოთვლის სახელთა სივრცის წესებს, და Resolve-DnsName პასუხობს ზუსტ სახელს სისტემის გზით. შეადარეთ ეს პასუხი VPN-ის სერვერზე მისამართით პირდაპირ მოთხოვნას. როცა Resolve-DnsName ვარდება და პირდაპირი მოთხოვნა წარმატდება, ეჭვმიტანილი ამომხსნელების სია ან სახელთა სივრცის წესია.
შეამოწმეთ თავად სახელიც. შიდა მოკლე სახელს შეიძლება სჭირდებოდეს კერძო სუფიქსი, რომელსაც მხოლოდ VPN ადაპტერი იძლევა, მაშინ როცა სრულად კვალიფიციური სახელი კარგად იხსნება. წარმატებული ძიების შემდეგ სერთიფიკატის გაფრთხილება სხვა პრობლემას ეკუთვნის.
მიუწვდომელი გაგზავნილი ამომხსნელი
კარიბჭეს ან კლიენტს შეუძლია გაგზავნოს ამომხსნელის მისამართი, და ეს მისამართი გვირაბით უნდა იყოს მისაწვდომი. split გვირაბში ამომხსნელის შემცველი კერძო დიაპაზონი შეიძლება არ იყოს ჩართულ მარშრუტებში, რაც იძლევა ძიებას, რომელიც არასოდეს იღებს პასუხს. დაადასტურეთ, რომ მარშრუტი არსებობს, შემდეგ ჰკითხეთ სწორედ იმ მისამართს გვირაბით. ეს არის ის წარუმატებლობა, რომელიც დგას ბრაუზერის დომენის შეცდომის უკან, მაშინ როცა საჯარო ამომხსნელი ჯერ კიდევ პასუხობს.
თუ ამომხსნელი მიუწვდომელია, შეკეთება მარშრუტი ან ჩართული ქვექსელია, და არა სხვა DNS სერვერი.
დაშიფრული DNS მთელ გზას გვერდს უვლის
DNS-over-HTTPS-ის მქონე ბრაუზერები სახელებს თავად ხსნიან HTTPS კავშირით შერჩეულ პროვაიდერთან. როცა ეს ჩართულია, სისტემის ამომხსნელი და split DNS წესები სრულად გვერდს უვლის ამ ძიებებს, ამიტომ შიდა სახელები ბრაუზერში ვარდება, მაშინ როცა ოპერაციული სისტემა მათ სწორად ხსნის. საპირისპიროც ხდება: შიდა სახელები ბრაუზერში წარმატდება პროვაიდერის მეშვეობით, რომელსაც არასოდეს უნდა ენახა ისინი, და ეს პოლიტიკის და არა კავშირის პრობლემაა.
შეგნებულად გადაწყვიტეთ, დაშვებულია თუ არა დაშიფრული DNS მართვად მოწყობილობებზე, შემდეგ დააკონფიგურირეთ ბრაუზერის მართვის ზედაპირიდან, რათა არჩევანი ხილული იყოს. ინდივიდუალურ უპირატესობაზე მიშვება ქმნის ფლოტს, სადაც იგივე VPN ყოველ ლეპტოპზე სხვაგვარად იქცევა.
წარუმატებლობის შესაბამისი შეკეთებები
თუ VPN თავის ამომხსნელს აგზავნის, უზრუნველყავით, რომ გვირაბმა ტრაფიკი მისკენ ატაროს და იგივე პარამეტრი ხილული იყოს ამოხსნაში მონაწილე ადაპტერებზე. თუ ადგილობრივი საიტები დაკავშირებულ მდგომარეობაში წყვეტენ ამოხსნას, დაამატეთ მკაფიო სახელთა სივრცის გამონაკლისები ან პირობითი გადამყვანი ამომხსნელის სრულად შეცვლის ნაცვლად. თუ ბრაუზერის დაშიფრული DNS პოლიტიკას გვერდს უვლის, სწორედ ეს პარამეტრი უნდა შეიცვალოს. არასოდეს დაამატოთ საჯარო ამომხსნელი შიდა სახელის გასწორებისთვის: ის ამჟღავნებს კერძო მოთხოვნებს და არ ხსნის სახელს.
შემდეგ გამოჰყავით ძიება კავშირისგან. სახელი, რომელიც სწორ მისამართზე იხსნება, მაგრამ კავშირზე უარს ამბობს, სერვისის, ფაირვოლის ან სერთიფიკატის პრობლემაა, და DNS ცვლილებები მას არ გამოასწორებს.
ჩაწერეთ, რომელმა გზამ უპასუხა, რომელი ვარდა და რა შეცვალეთ. მაშინ იგივე სიმპტომის შემდეგი ანგარიში ნახევარი დღის ნაცვლად ერთ ბრძანებას მოითხოვს.