Split-DNS-ის აღება: თქვით, სად გაკეთდა ყოველი დაკვირვება

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

ერთი ძებნა, რამდენიმე დაკვირვების წერტილი

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

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

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

კლიენტის ფილტრი აპლიკაციასა და მავთულს შორის ზის

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

Cisco-ს Secure Client-ის Split-DNS სახელმძღვანელო დომენის შესაბამისობასა და Windows-ის ფილტრს მოიცავს და გამოჰყოფს იმას, რასაც აპლიკაცია ხედავს მშობლიური resolver API-ის გამოყენებისას, იმისგან, რასაც nslookup-ის მსგავსი ხელსაწყო ხედავს. სწორედ ეს განსხვავებებია მთავარი.

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

nslookup აპლიკაციისგან განსხვავებულ გზას მიჰყვება

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

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

წაიკითხეთ პოლიტიკა და შემდეგ იგივე კითხვა ჩვეულებრივი resolver-ის მეშვეობით დასვით:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

დაშიფრული resolver-ები მოთხოვნას მალავენ, კავშირს არა

ბრაუზერი საკუთარი DNS-over-HTTPS resolver-ით სრულიად სხვა შემთხვევაა. მოთხოვნა TLS-ის შიგნით გადის, ამიტომ პაკეტის აღება resolver-ის მისამართთან კავშირს აჩვენებს, მაგრამ არა კითხვის სახელს.

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

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

შეადარეთ ეტიკეტირებულ ტესტს

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

სადაც დასაშვებია, შეადარეთ resolver-ის მიღება კლიენტის ან კარიბჭის ერთ ვიწრო დაკვირვებას:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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