SOCKS პროქსის შეუძლია შეტყობინებების ჩატვირთვა, მაგრამ ზარებზე ვარდება
Dante-ს სახელმძღვანელოსა და SOCKS5-ის UDP მოთხოვნების მეშვეობით აიხსნება, რატომ არ ამტკიცებს მოქმედი TCP გზა აპლიკაციის ზარების ტრაფიკის მხარდაჭერას.
ტექსტური შეტყობინებები SOCKS პროქსით მოდის, მაგრამ ხმოვანი ზარი არასოდეს დაკავშირდება. პროქსი სულაც არ არის სრულად გაფუჭებული. შესაძლოა აპლიკაცია ზარებისთვის სხვა ტრანსპორტს იყენებს.
წარმატებული TCP მოთხოვნა ამტკიცებს TCP გზას ამ ოპერაციისთვის. SOCKS5 ასევე განსაზღვრავს UDP ასოციაციას, მაგრამ კლიენტი, SOCKS სერვისი, ქსელის წესები და აპლიკაციის პარამეტრები ყველამ უნდა დაუჭიროს მხარი განზრახულ UDP მარშრუტს.
არსებობს უფრო მეტი, ვიდრე TCP მსმენელი
Dante-ს სახელმძღვანელო ჰყოფს პროტოკოლისა და ბრძანების წესებს, მათ შორის connect, udpassociate და udpreply. წესი, რომელიც მხოლოდ უკვე გამოცდილ TCP კავშირს უშვებს, არ ადგენს საჭირო UDP ნებართვებს.
UDP ასოციაცია ასევე მოიცავს გადაცემის საბოლოო წერტილს და დაბრუნების ტრაფიკს. ქსელის დაცვამ და მისამართების თარგმნამ უნდა დაუშვას სწორედ ეს რეალური გზა. SOCKS-ის TCP მსმენელის გახსნა არ უდრის მისი UDP გადამცემის ხელმისაწვდომობას.
შეამოწმეთ აპლიკაციის მიმდინარე პროქსის დოკუმენტაცია და პარამეტრები. სხვადასხვა ვერსია შეტყობინებებს, მედიასა და ზარებს სხვადასხვაგვარად შეიძლება მართავდეს. ძველი კლიენტისთვის ფორუმის რეცეპტი არ უნდა წარმოდგეს როგორც მტკიცებულება, რომ ყოველი ამჟამინდელი კლიენტი ზარებს SOCKS-ით აგზავნის.
თავიდან აიცილეთ ყველა UDP პორტის გახსნა პირველ დიაგნოზად. განსაზღვრეთ გადამცემის ქცევა და განზრახული კლიენტების არეალი, შემდეგ გამოიყენეთ შესაბამისი შეზღუდული ქსელური პოლიტიკა. ანალოგიურად, ზარებისთვის პროქსის პარამეტრის გამორთვამ შეიძლება ზარი იმუშაოს უშუალოდ გაგზავნით, რაც ცვლის გარე მარშრუტს და არა ამრავალებს პროქსირებულს.
დააფიქსირეთ წარმატება ოპერაციების მიხედვით: შეტყობინებები, მედიის გადაცემა და ზარები. ერთი მოქმედი მოთხოვნა ან შეცვლილი ბრაუზერის IP ვერ დაამტკიცებს, რომ სხვა აპლიკაციის ყოველი ნაწილი ერთსა და იმავე პროქსის გასასვლელს იზიარებს.