आपका स्प्लिट टनल लॉन्चर को बाहर रखता है, गेम को नहीं
लॉन्चर मैच के लिए दूसरी निष्पादन योग्य फ़ाइल शुरू करता है, और उस प्रक्रिया के अपने सॉकेट होते हैं। असली प्रक्रिया खोजें, सही पहचानकर्ता मिलाएँ, फिर परीक्षण करें।
आप लॉन्चर को बहिष्करण सूची में जोड़ते हैं, डाउनलोड धीमे से तेज़ हो जाता है, और मैच फिर भी दूर के सर्वर पर पहुँचता है। कुछ भी टूटा नहीं है। लॉन्चर और गेम दो प्रक्रियाएँ हैं जिनके सॉकेट के दो सेट हैं, और एक को बाहर रखना दूसरे के बारे में कुछ नहीं कहता। डाउनलोड तेज़ हुआ क्योंकि डाउनलोड लॉन्चर का ट्रैफ़िक था; मैच किसी और का कनेक्शन है, जिसे ऐसी निष्पादन योग्य फ़ाइल ने खोला है जिसे आपके नियम ने कभी नहीं देखा।
एक इंस्टॉलर, कई प्रक्रियाएँ
आधुनिक गेम सॉफ़्टवेयर एक छोटा तारामंडल है। एक क्लाइंट है जो आपको साइन इन कराता है, एक अपडेटर जो सामग्री खींचता है, एक लॉन्चर जो गेम शुरू करता है, और एक गेम निष्पादन योग्य फ़ाइल जो स्वयं एंटी-चीट या मैचमेकिंग ओवरले के लिए दूसरी प्रक्रिया पैदा कर सकती है। इनमें से हर एक अपने गंतव्यों के लिए अपने कनेक्शन रख सकता है।
बहिष्करण नियम आमतौर पर इनमें से एक का नाम लेता है। किसका नाम लेगा यह पूरी तरह उस पहचानकर्ता पर निर्भर है जिसे 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
पहले आदेश को वह पता चाहिए जिस पर मैच सर्वर हल हुआ, जो गेम का कनेक्शन लॉग या आपका क्लाइंट दे सकता है। यदि मार्ग भौतिक इंटरफ़ेस का नाम लेता है, तो नियम काम कर रहा है। दूसरा दिखाता है कि सत्र है भी या नहीं, जो “बाहर रखा गया लेकिन सर्वर बंद है” को “बाहर नहीं रखा गया” से अलग करता है।
परीक्षण के दौरान क्षेत्र और पहुँच नेटवर्क स्थिर रखें। जो मैच हर प्रयास में अलग डेटा सेंटर में पहुँचता है वह अलग पते बनाता है, और आप नियम सत्यापित करने के बजाय चलते लक्ष्य का पीछा करेंगे। एक ही पते के साथ दो रन अलग पतों के साथ दस से अधिक मूल्य के हैं।
अगले अपडेट के बाद फिर जाँचें
पथ आधारित किसी भी नियम का पैच चक्रों में मापा गया जीवनकाल होता है। जब गेम एक महीने बाद बहिष्करण का सम्मान करना बंद कर देता है, तो पहली चीज़ जाँचें कि निष्पादन योग्य फ़ाइल हटी है या नहीं, और दूसरी कि उसके साथ नई सहायक प्रक्रिया आई है या नहीं।
एक क्लाइंट द्वारा प्रलेखित एप्लिकेशन बहिष्करण मॉडल इन नियमों का वर्णन कैसे किया जाता है इसका उचित संदर्भ है, हालाँकि विवरण उत्पादों के बीच भिन्न होते हैं। अपना पढ़ें, उपयोग किया गया पहचानकर्ता दर्ज करें, और तारीख लिखें। यही रिकॉर्ड अगली बार लॉन्चर के अपडेट भेजने पर एक रहस्य को पाँच मिनट के सुधार में बदलता है।
यदि क्लाइंट वह सीमा व्यक्त ही नहीं कर सकता जिसकी आपको आवश्यकता है, तो स्वीकृत व्यापक नीति अप्रलेखित अपवादों के ढेर से बेहतर है। व्यापक और समझा हुआ संकीर्ण और गलत से बेहतर है, विशेषकर जब संकीर्ण संस्करण वही हो जिसे सब मानते हैं कि लागू है।