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