თქვენი VPN DNS-ს შიფრავს თუ მხოლოდ შემდეგ ნახტომს?

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

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

ორი განლაგება პარამეტრების გვერდზე ერთნაირად გამოიყურება

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

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

გამხსნელების ჯაჭვი გაისახეთ მის შეცვლამდე

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

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

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

შეამოწმეთ, რომელი ნახტომია დაშიფრული

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

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

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

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

ჩაწერეთ მფლობელი და წარუმატებლობის ქცევა

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

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

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