რატომ ვერ აყენებს DNS ცვლილება SOCKS პროქსის

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

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

ეს ხსნის, რატომ შეიძლება ხელმისაწვდომმა Dante-ის მსმენელმა დაუყოვნებლივ დახუროს კავშირი DNS ცვლილების შემდეგ. სერვისი შეიძლება ჯანმრთელი იყოს; შემომავალი ბაიტები არასწორ პროტოკოლს ეკუთვნის. მსმენელის 80 ან 443 პორტზე გადატანა ამ ბაიტებს SOCKS-ად არ აქცევს.

მოაწყვეთ ბრაუზერის SOCKS ინტერფეისი, მაგალითად Firefox-ის SOCKS პარამეტრები, ან აპლიკაციისთვის დამახასიათებელი პროქსის პარამეტრი, რათა მან შეასრულოს ხელის ჩამორთმევა და სთხოვოს პროქსის შემდგომი დაკავშირება. PAC ფაილს შეუძლია აირჩიოს მხარდაჭერილი პროქსის მარშრუტი მისთვის, ვინც მას იყენებს. ეს მაინც ცალკე პროქსის კონფიგურაციაა და არა A ან AAAA ჩანაწერის თვისება.

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

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