টেক্সট বার্তা SOCKS প্রক্সির মধ্য দিয়ে আসে, কিন্তু ভয়েস কল কখনো সংযুক্ত হয় না। প্রক্সিটি অবশ্যই সম্পূর্ণ বিকল নাও হতে পারে। অ্যাপ্লিকেশনটি কলে ভিন্ন পরিবহন ব্যবহার করতে পারে।

সফল TCP অনুরোধ সেই কাজের জন্য একটি TCP পথ প্রমাণ করে। SOCKS5 আরও UDP সংযোগ সংজ্ঞায়িত করে, কিন্তু ক্লায়েন্ট, SOCKS পরিষেবা, নেটওয়ার্ক নিয়ম এবং অ্যাপ্লিকেশন সেটিংস সবই লক্ষ্যকৃত UDP পথ সমর্থন করতে হবে।

TCP লিসেনারের চেয়ে বেশি কিছু আছে

Dante ম্যানুয়াল প্রোটোকল এবং কমান্ড নিয়ম আলাদা করে, যার মধ্যে connect, udpassociate এবং udpreply রয়েছে। যে নিয়ম শুধু আপনার ইতিমধ্যে পরীক্ষিত TCP সংযোগ অনুমোদন করে, তা প্রয়োজনীয় UDP অনুমতি প্রতিষ্ঠা করে না।

UDP সংযোগে একটি রিলে এন্ডপয়েন্ট এবং ফেরত ট্রাফিকও জড়িত। ফায়ারওয়াল এবং ঠিকানা অনুবাদকে সেই প্রকৃত পথ অনুমোদন করতে হবে। SOCKS TCP লিসেনার খোলা তার UDP রিলে পৌঁছানোযোগ্য করার সমান নয়।

অ্যাপ্লিকেশনের বর্তমান প্রক্সি ডকুমেন্টেশন ও সেটিংস পরীক্ষা করুন। বিভিন্ন সংস্করণ বার্তা, মিডিয়া ও কল ভিন্নভাবে সামলাতে পারে। পুরোনো ক্লায়েন্টের জন্য ফোরামের রেসিপি প্রতিটি বর্তমান ক্লায়েন্ট কল SOCKS-এর মধ্য দিয়ে পাঠায় এর প্রমাণ হিসেবে উপস্থাপন করা উচিত নয়।

প্রথম রোগনির্ণয় হিসেবে প্রতিটি UDP পোর্ট খোলা এড়িয়ে চলুন। রিলে আচরণ এবং লক্ষ্যকৃত ক্লায়েন্ট পরিধি নির্ধারণ করুন, তারপর উপযুক্ত সীমিত নেটওয়ার্ক নীতি প্রয়োগ করুন। একইভাবে, কলে প্রক্সি সেটিংস নিষ্ক্রিয় করা কলটি সরাসরি পাঠিয়ে কাজ করাতে পারে, যা প্রক্সিকৃত পথ মেরামতের বদলে বাহ্যিক পথ বদলে দেয়।

প্রতিটি কাজের সাফল্য নথিভুক্ত করুন: বার্তা, মিডিয়া স্থানান্তর এবং কল। একটি কার্যকর অনুরোধ বা পরিবর্তিত ব্রাউজার IP প্রমাণ করতে পারে না যে অন্য অ্যাপ্লিকেশনের প্রতিটি অংশ একই প্রক্সি এক্সিট ভাগ করে।

সম্পর্কিত নিবন্ধ