ვრცელდება ბრაუზერის პროქსი WebRTC-ზეც?
ჩვეულებრივი ვებ IP შემოწმება და WebRTC კავშირი შეიძლება სხვადასხვა გზას იყენებდეს. ბრაუზერის რეალურ დროში კომუნიკაცია ცალკე შეამოწმეთ.
ბრაუზერის HTTP პროქსის პარამეტრი WebRTC-ზე ავტომატურად არ ვრცელდება. IP-ის ჩვეულებრივი შემოწმების გვერდი ვებმოთხოვნას ზომავს; ზარმა დაკავშირებისა და მისამართების აღმოჩენისთვის შეიძლება ცალკე გზები გამოიყენოს.
SOCKS5 ამ განსხვავებას არ აუქმებს. Chromium-ში ჩაშენებული SOCKS5 URL პროქსის რეალიზაცია TCP-ს უჭერს მხარს და არა ზოგადი დანიშნულების UDP ასოციაციას. პროტოკოლის შესაძლებლობები ბრაუზერის ამ ინტერფეისზე ფართოა.
ბრაუზერები WebRTC-ისთვის ცალკე ქსელურ კონტროლს იძლევა. Chrome კონფიდენციალურობის გაფართოებების API-ით IP დამუშავების პოლიტიკას გვთავაზობს, მათ შორის disable_non_proxied_udp-ს; Mozilla-ც აღწერს WebRTC-ის ქსელური კონფიდენციალურობის პარამეტრებს. Chrome-ის ეს მნიშვნელობა API-ის პოლიტიკაა და არა უნივერსალური მოსანიშნი ველი ან ყველა მისამართის დამალვის გარანტია.
შეამოწმეთ ჩვეულებრივი ვებგასასვლელი, შემდეგ კი WebRTC-ის ქცევა იმ საკონფერენციო აპში, რომელსაც რეალურად იყენებთ, ისეთი დიაგნოსტიკით, რომლის ანგარიშის ველების მნიშვნელობაც გესმით. ლოკალური მისამართები, რელეს მისამართები და გარედან დანახული საჯარო მისამართები კავშირის სხვადასხვა ნაწილს აღწერს. ჩაიწერეთ ბრაუზერი და ტესტის პირობები: პოლიტიკები, გაფართოებები, კონფიდენციალურობის ქცევა და ხელმისაწვდომი გზები შედეგზე მოქმედებს. ამიტომ არც „ყოველთვის ჟონავს“ და არც წარმატებული ვებ IP შემოწმება საკმარისი დასკვნა არ არის.
თუ WebRTC-ის გზას ზღუდავთ, საჭირო ზარები ხელახლა გამოცადეთ. მისამართების გამჟღავნების შემცირებამ შეიძლება ზარის დაკავშირებაც შეაფერხოს. ეს კომპრომისი ცალკეა იმისგან, HTTP პროქსის წერტილი ონლაინ არის თუ არა.