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