আপনার স্প্লিট টানেল লঞ্চারকে বাদ দেয়, গেমটিকে নয়
লঞ্চার ম্যাচের জন্য আরেকটি এক্সিকিউটেবল চালু করে, এবং সেই প্রক্রিয়ার নিজের সকেট থাকে। প্রকৃত প্রক্রিয়াটি খুঁজুন, সঠিক শনাক্তকারক মিলান, তারপর পরীক্ষা করুন।
আপনি লঞ্চারটিকে বর্জন তালিকায় যোগ করেন, ডাউনলোড ধীর থেকে দ্রুত হয়ে যায়, আর ম্যাচটি তবুও দূরের সার্ভারে গিয়ে পড়ে। কিছুই ভাঙা নেই। লঞ্চার ও গেম দুটি প্রক্রিয়া, দুটি আলাদা সকেট সেট, আর একটিকে বাদ দিলে অন্যটি সম্পর্কে কিছুই বলা হয় না। ডাউনলোড দ্রুত হয়েছে কারণ ডাউনলোডটি ছিল লঞ্চারের ট্র্যাফিক; ম্যাচটি অন্য কারও সংযোগ, যা খুলেছে এমন একটি এক্সিকিউটেবল যেটি আপনার নিয়ম কখনও দেখেনি।
এক ইনস্টলার, অনেক প্রক্রিয়া
আধুনিক গেম সফটওয়্যার একটি ছোট নক্ষত্রমণ্ডল। একটি ক্লায়েন্ট আছে যা আপনাকে সাইন ইন করায়, একটি আপডেটার যা কনটেন্ট টেনে আনে, একটি লঞ্চার যা গেম চালু করে, এবং একটি গেম এক্সিকিউটেবল যা নিজেই অ্যান্টি-চিট বা ম্যাচমেকিং ওভারলের জন্য দ্বিতীয় প্রক্রিয়া জন্ম দিতে পারে। এদের প্রত্যেকেই নিজের গন্তব্যে নিজের সংযোগ ধরে রাখতে পারে।
বর্জন নিয়ম সাধারণত এদের একটির নাম নেয়। কোনটির নাম নেবে তা সম্পূর্ণভাবে নির্ভর করে VPN ক্লায়েন্ট যে শনাক্তকারক সমর্থন করে তার উপর, আর এটিই সেই অংশ যা ব্যবহারকারীরা খুব কমই যাচাই করেন। কিছু ক্লায়েন্ট এক্সিকিউটেবল পাথ মেলায়, কিছু বান্ডল বা প্যাকেজ শনাক্তকারক মেলায়, আর কিছু প্রক্রিয়ার নাম মেলায় যা দুটি সম্পর্কহীন বাইনারি ভাগ করতে পারে। প্রক্রিয়া তালিকা পড়ার আগে নিয়মটি পড়ুন, কারণ নিয়মটি আপনি কী প্রকাশ করতে পারবেন তাও সীমাবদ্ধ করে।
তাই লক্ষণটি “স্প্লিট টানেল ভাঙা” নয়। এটি হলো “নিয়মটি এমন একটি প্রক্রিয়া ঢাকে যা আমার কাছে গুরুত্বপূর্ণ ট্র্যাফিক বহনকারী প্রক্রিয়া নয়”, যা অনেক সংকীর্ণ এবং অনেক বেশি সংশোধনযোগ্য একটি বক্তব্য। একবার এভাবে বললে পরের ধাপটি আর অনুমান থাকে না।
ম্যাচ সংযোগের মালিক প্রক্রিয়াটি খুঁজুন
গেম চালু করুন, একটি ম্যাচে ঢুকুন, এবং স্ক্রিনে কী আছে তা নয়, সকেটগুলোর মালিক কে তা দেখুন। Windows-এ প্রক্রিয়া তালিকার সঙ্গে প্রতি প্রক্রিয়ার সকেট জিজ্ঞাসা দুটি কমান্ডে এর উত্তর দেয়:
Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess
দ্বিতীয় কমান্ডটি নাম নয়, একটি প্রক্রিয়া আইডি ছাপে, তাই দুটি আউটপুট আইডি দিয়ে জোড়া লাগান। আপনি যে সারিটি খুঁজছেন সেটি হলো যার দূরবর্তী ঠিকানা গেম পরিষেবার অন্তর্গত, আর তার মালিক প্রক্রিয়াটি হলো সেই এক্সিকিউটেবল যার নাম আপনার নিয়মে দিতে হবে।
Linux-এ একই প্রশ্নের জন্য প্রতিটি সকেট ধরনের একেকটি কমান্ড লাগে, এবং দুটোই যাচাই করা উচিত, কারণ ম্যাচ সংযোগ UDP হতে পারে যখন বাকি সব TCP:
ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'
গেমটি কন্টেইনার বা সামঞ্জস্য স্তরে চললে আপনি যে প্রক্রিয়া পান সেটি ইনস্টল করা বাইনারি নয়, একটি শিম হতে পারে। সেক্ষেত্রে গুরুত্বপূর্ণ শনাক্তকারকটি হলো যা ক্লায়েন্ট দেখে, যা শিমের পাথ হতে পারে, এবং মূল ফাইল যতই সম্পাদনা করুন না কেন তাতে কোনো প্রভাব পড়বে না।
আপনার ক্লায়েন্ট যে শনাক্তকারক সমর্থন করে তা মিলান
কিছু যোগ করার আগে বর্জন নিয়মের জন্য ক্লায়েন্টের ডকুমেন্টেশন পড়ুন। তিনটি সাধারণ মডেল ভিন্নভাবে আচরণ করে, আর তাদের একটি ফাঁদ।
| Identifier | How it behaves | Failure mode |
|---|---|---|
| Executable path | Matches exactly the file at that path | Breaks when an update moves the binary |
| Process name | Matches any binary with that name | Too broad; catches unrelated software |
| Package or bundle id | Matches a signed application group | May include services you did not intend |
পাথ নিয়ম সবচেয়ে নিখুঁত এবং সবচেয়ে ভঙ্গুর। যে লঞ্চার আপডেট এক্সিকিউটেবলকে সরিয়ে দেয় নিয়মটিকে এমন ফাইলের দিকে নির্দেশ করে রাখে যা আর চলে না, এবং স্পষ্টভাবে কিছু না বদলেও লক্ষণটি ফিরে আসে। প্যাকেজ নিয়ম এটা টিকে যায়, এবং তারা চুপচাপ এমন সহায়ক প্রক্রিয়াও ঢাকতে পারে যা আপনি কখনও ভাবেননি, যা সহায়ক প্রক্রিয়ার উপর নির্ভর করে সুবিধাজনক বা উদ্বেগজনক।
ক্লায়েন্ট যাই সমর্থন করুক, আপনি যত এক্সিকিউটেবল পান সবগুলোর জন্য এন্ট্রি যোগ করবেন না। একটি সেশন কাজ করা পর্যন্ত পরীক্ষা-ভুলে জোড়া একটি তালিকা পুনর্বিবেচনার অযোগ্য, এবং এটি অসম্পর্কিত সফটওয়্যারের জন্য চুপচাপ ব্যতিক্রম জমাতে থাকবে। আপনি যে প্রক্রিয়াটি পেয়েছেন তার নাম দিন, এবং এটি কীসের জন্য ছিল তা লিখে রাখুন।
ম্যাচে পরীক্ষা করুন, ডাউনলোডে নয়
লঞ্চারের ডাউনলোড গতি সম্ভাব্য সবচেয়ে খারাপ পরীক্ষা, কারণ এটি ঠিক সেই প্রক্রিয়াটিকেই চালায় যা ইতিমধ্যে বাদ দেওয়া হয়েছে। যে জিনিসটি ব্যর্থ হচ্ছিল সেটি ব্যবহার করুন, এবং গেমের নিজের পারফরম্যান্স প্রদর্শনের বদলে পথটি যাচাই করুন:
ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015
প্রথম কমান্ডের জন্য ম্যাচ সার্ভার যে ঠিকানায় রিজলভ হয়েছে সেটি দরকার, যা গেমের সংযোগ লগ বা আপনার ক্লায়েন্ট দিতে পারে। রুটটি যদি ভৌত ইন্টারফেসের নাম বলে, তাহলে নিয়মটি কাজ করছে। দ্বিতীয়টি দেখায় আদৌ কোনো সেশন আছে কি না, যা “বাদ দেওয়া হয়েছে কিন্তু সার্ভার বন্ধ” এবং “বাদ দেওয়া হয়নি”-এর মধ্যে পার্থক্য করে।
পরীক্ষার সময় অঞ্চল ও অ্যাক্সেস নেটওয়ার্ক স্থির রাখুন। যে ম্যাচ প্রতিবার ভিন্ন ডেটা সেন্টারে পড়ে সেটি ভিন্ন ঠিকানা তৈরি করে, আর আপনি নিয়ম যাচাই করার বদলে চলমান লক্ষ্য তাড়া করবেন। একই ঠিকানায় দুটি রান ভিন্ন ঠিকানায় দশটির চেয়ে বেশি মূল্যবান।
পরের আপডেটের পরে আবার যাচাই করুন
পাথ-ভিত্তিক যেকোনো নিয়মের প্যাচ চক্রে মাপা আয়ু থাকে। এক মাস পরে গেমটি বর্জন মানা বন্ধ করলে প্রথমে দেখতে হবে এক্সিকিউটেবলটি সরে গেছে কি না, আর দ্বিতীয়টি হলো তার পাশে নতুন সহায়ক প্রক্রিয়া এসেছে কি না।
একটি ক্লায়েন্টের নথিভুক্ত অ্যাপ্লিকেশন বর্জন মডেল এই নিয়মগুলো কীভাবে বর্ণনা করা হয় তার একটি যুক্তিসঙ্গত রেফারেন্স, যদিও বিস্তারিত পণ্যভেদে ভিন্ন। আপনারটি পড়ুন, আপনি যে শনাক্তকারক ব্যবহার করেছেন তা লিখুন, এবং তারিখ টুকে রাখুন। সেই রেকর্ডই পরের বার লঞ্চার আপডেট পাঠালে একটি রহস্যকে পাঁচ মিনিটের সমাধানে বদলে দেয়।
ক্লায়েন্ট যদি সত্যিই আপনার প্রয়োজনীয় সীমা প্রকাশ করতে না পারে, তবে অনুমোদিত বিস্তৃত নীতি নথিবিহীন ব্যতিক্রমের স্তূপের চেয়ে ভালো। বিস্তৃত ও বোঝা যায় এমন সংকীর্ণ ও ভুলের চেয়ে ভালো, বিশেষত যখন সংকীর্ণ সংস্করণটিই সবাই মনে করে কার্যকর আছে।