VPN DNS-ის გავლით არ არის იგივე, რაც VPN-ის DNS სერვერი

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

გამოყავით სამი განლაგება

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

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

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

შეამოწმეთ, რას გადააქვთ DNS შეტყობინებებს

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

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

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

შეამოწმეთ ტევადობა ვალდებულების აღებამდე

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

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

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

შეამოწმეთ მატარებლის უსაფრთხოება

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

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

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

შეუსაბამეთ გამოსწორება ფაქტობრივ ხარვეზს

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

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

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