તમારું સ્પ્લિટ ટનલ લોન્ચરને બાકાત રાખે છે, રમતને નહીં
લોન્ચર મેચ માટે બીજી એક્ઝિક્યુટેબલ શરૂ કરે છે અને તે પ્રક્રિયાના પોતાના સોકેટ હોય છે. વાસ્તવિક પ્રક્રિયા શોધો, યોગ્ય ઓળખકર્તા મેળવો, પછી પરીક્ષણ કરો.
તમે લોન્ચરને બાકાત યાદીમાં ઉમેરો છો, ડાઉનલોડ ધીમાથી ઝડપી થઈ જાય છે, અને મેચ હજી પણ દૂરના સર્વર પર ઉતરે છે. કંઈ તૂટ્યું નથી. લોન્ચર અને રમત બે પ્રક્રિયાઓ છે જેમની પાસે સોકેટના બે સેટ છે, અને એકને બાકાત રાખવાથી બીજા વિશે કંઈ કહેવાતું નથી. ડાઉનલોડ ઝડપી થયું કારણ કે ડાઉનલોડ લોન્ચરનો ટ્રાફિક હતો; મેચ બીજા કોઈનું જોડાણ છે, જે એક એક્ઝિક્યુટેબલે ખોલ્યું છે જે તમારો નિયમે ક્યારેય જોયું નથી.
એક ઇન્સ્ટોલર, ઘણી પ્રક્રિયાઓ
આધુનિક રમત સૉફ્ટવેર એક નાનું નક્ષત્ર છે. એક ક્લાયન્ટ છે જે તમને સાઇન ઇન કરાવે છે, એક અપડેટર છે જે સામગ્રી ખેંચે છે, એક લોન્ચર છે જે રમત શરૂ કરે છે, અને એક રમત એક્ઝિક્યુટેબલ છે જે પોતે એન્ટી-ચીટ અથવા મેચમેકિંગ ઓવરલે માટે બીજી પ્રક્રિયા બનાવી શકે છે. તેમાંથી દરેક પોતાના ગંતવ્યો સાથે પોતાના જોડાણો રાખી શકે છે.
બાકાત નિયમ સામાન્ય રીતે તેમાંથી એકનું નામ લે છે. કયા એકનું નામ લે તે સંપૂર્ણપણે 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પ્રથમ આદેશને મેચ સર્વર જે સરનામા પર ઉકેલાયું તેની જરૂર છે, જે રમતનો જોડાણ લોગ અથવા તમારો ક્લાયન્ટ આપી શકે. જો રૂટ ભૌતિક ઇન્ટરફેસનું નામ લે છે, તો નિયમ કામ કરે છે. બીજો બતાવે છે કે સત્ર છે કે નહીં, જે “બાકાત પણ સર્વર બંધ” અને “બાકાત નથી” વચ્ચે ભેદ કરે છે.
પરીક્ષણ દરમિયાન પ્રદેશ અને પ્રવેશ નેટવર્ક સ્થિર રાખો. જે મેચ દરેક પ્રયાસે અલગ ડેટા સેન્ટરમાં ઉતરે છે તે અલગ સરનામાં બનાવે છે, અને તમે નિયમની માન્યતા ચકાસવાને બદલે ચાલતા લક્ષ્યનો પીછો કરશો. એક જ સરનામા સાથેની બે રન અલગ સરનામાં સાથેની દસ કરતાં વધુ મૂલ્યવાન છે.
આગલા અપડેટ પછી ફરી તપાસો
પાથ આધારિત કોઈપણ નિયમનું પેચ ચક્રમાં માપેલું આયુષ્ય હોય છે. જ્યારે રમત એક મહિના પછી બાકાતને માન આપવાનું બંધ કરે, ત્યારે પ્રથમ તપાસવાનું એ છે કે એક્ઝિક્યુટેબલ ખસ્યું છે કે નહીં, અને બીજું એ કે તેની બાજુમાં નવી સહાયક પ્રક્રિયા આવી છે કે નહીં.
એક ક્લાયન્ટ દ્વારા દસ્તાવેજીકૃત એપ્લિકેશન બાકાત મોડેલ આ નિયમો કેવી રીતે વર્ણવાય છે તે માટે વાજબી સંદર્ભ છે, જોકે વિગતો ઉત્પાદનો વચ્ચે અલગ પડે છે. તમારું વાંચો, તમે વાપરેલો ઓળખકર્તા નોંધો, અને તારીખ લખો. એ જ રેકોર્ડ છે જે આગલી વાર લોન્ચર અપડેટ મોકલે ત્યારે રહસ્યને પાંચ મિનિટના સુધારામાં ફેરવે છે.
જો ક્લાયન્ટ ખરેખર તમને જરૂરી સીમા વ્યક્ત કરી શકતું નથી, તો મંજૂર વિશાળ નીતિ અદસ્તાવેજીકૃત અપવાદોના ઢગલા કરતાં સારી છે. વિશાળ અને સમજાય તેવું સાંકડા અને ખોટા કરતાં સારું છે, ખાસ કરીને જ્યારે સાંકડું સંસ્કરણ જ તે છે જે બધા માને છે કે અમલમાં છે.