Jy voeg die opstartprogram by die uitsluitingslys, die aflaai skiet van stadig na vinnig, en die wedstryd beland steeds op 'n verre bediener. Niks is stukkend nie. Die opstartprogram en die speletjie is twee prosesse met twee stelle sokke, en om een uit te sluit sê niks oor die ander nie. Die aflaai het vinniger geword omdat die aflaai die opstartprogram se verkeer was; die wedstryd is iemand anders se verbinding, oopgemaak deur 'n uitvoerbare lêer wat jou reël nog nooit gesien het nie.

Een installeerder, baie prosesse

Moderne speletjiesagteware is 'n klein sterrebeeld. Daar is 'n kliënt wat jou aanmeld, 'n opdateerder wat inhoud aflaai, 'n opstartprogram wat die speletjie begin, en 'n speletjie-uitvoerbare lêer wat self 'n tweede proses kan skep vir teenbedrog of vir die wedstrydsoorkapping. Elkeen van dié kan sy eie verbindings na sy eie bestemmings hou.

'n Uitsluitingsreël noem gewoonlik een van hulle. Watter een dit noem, hang heeltemal af van die identifiseerder wat die VPN-kliënt ondersteun, en dit is die deel wat gebruikers selde nagaan. Sommige kliënte pas 'n uitvoerbare pad, sommige 'n bondel- of pakketidentifiseerder, en sommige 'n prosesnaam wat twee onverwante binaries kan deel. Lees die reël voordat jy die proseslys lees, want die reël beperk wat jy selfs kan uitdruk.

Die simptoom is dus nie “split-tonnel is stukkend” nie. Dit is “die reël dek 'n proses wat nie die een is wat die verkeer dra waaraan ek omgee nie”, wat 'n baie smaller en baie meer herstelbare stelling is. Sodra jy dit so sê, hou die volgende stap op om te raai.

Vind die proses wat die wedstrydverbinding besit

Begin die speletjie, gaan in 'n wedstryd in en kyk wie die sokke besit eerder as wat op die skerm is. Op Windows beantwoord die proseslys plus 'n soknavraag per proses dit in twee opdragte:

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

Die tweede opdrag druk 'n proses-ID, nie 'n naam nie, so voeg die twee uitsette by ID saam. Die ry waarna jy soek, is die een wie se afgeleë adres aan die speletjiediens behoort, en sy besittende proses is die uitvoerbare lêer wat jou reël moet noem.

Op Linux neem dieselfde vraag een opdrag per soktipe, en dit is die moeite werd om albei na te gaan, want 'n wedstrydverbinding kan UDP wees terwyl alles anders TCP is:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

As die speletjie in 'n houer of 'n versoenbaarheidslaag loop, kan die proses wat jy vind 'n skil wees eerder as die binary wat jy geïnstalleer het. In daardie geval is die identifiseerder wat saak maak dié een wat die kliënt sien, wat die skil se pad kan wees, en geen hoeveelheid redigering van die oorspronklike lêer sal dit raak nie.

Pas die identifiseerder wat jou kliënt ondersteun

Lees die kliënt se dokumentasie vir die uitsluitingsreël voordat jy iets byvoeg. Die drie algemene modelle werk anders, en een van hulle is 'n lokval.

IdentifierHow it behavesFailure mode
Executable pathMatches exactly the file at that pathBreaks when an update moves the binary
Process nameMatches any binary with that nameToo broad; catches unrelated software
Package or bundle idMatches a signed application groupMay include services you did not intend

Padreëls is die akkuraatste en die broosste. 'n Opstartprogram-opdatering wat die uitvoerbare lêer verskuif laat die reël na 'n lêer wys wat nie meer loop nie, en die simptoom keer terug sonder dat iets ooglopend verander. Pakketreëls oorleef dit, en hulle kan ook stilweg helperprosesse dek waaraan jy nooit gedink het nie, wat óf gerieflik óf kommerwekkend is, afhangende van die helper.

Wat die kliënt ook al ondersteun, moenie inskrywings byvoeg vir elke uitvoerbare lêer wat jy kan vind nie. 'n Lys wat deur probeer en foute saamgestel is totdat een sessie gewerk het, is nie hersienbaar nie, en dit sal stilweg uitsonderings vir onverwante sagteware opbou. Noem die proses wat jy gevind het, en skryf neer waarvoor dit was.

Toets op die wedstryd, nie op 'n aflaai nie

Die opstartprogram se aflaaispoed is die slegste moontlike toets, want dit oefen presies die proses wat reeds uitgesluit is. Gebruik die ding wat gefaal het, en nagaan die pad eerder as die speletjie se eie werkvertoningskerm:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

Die eerste opdrag het die adres nodig waarna die wedstrydbediener opgelos het, wat die speletjie se verbindingslog of jou kliënt vir jou kan gee. As die roete die fisiese koppelvlak noem, werk die reël. Die tweede wys of daar hoegenaamd 'n sessie bestaan, wat “uitgesluit maar die bediener is af” van “nie uitgesluit nie” skei.

Hou die streek en die toegangsnetwerk vas terwyl jy toets. 'n Wedstryd wat elke poging op 'n ander datasentrum beland, lewer verskillende adresse, en jy sal uiteindelik 'n bewegende teiken jaag in plaas daarvan om 'n reël te valideer. Twee lopies met dieselfde adres is meer werd as tien met verskillende.

Gaan weer na die volgende opdatering na

Enige padgebaseerde reël het 'n rakleeftyd gemeet in patch-siklusse. Wanneer die speletjie 'n maand later ophou om die uitsluiting te respekteer, is die eerste ding om na te gaan of die uitvoerbare lêer verskuif het, en die tweede of 'n nuwe helperproses langs hom verskyn het.

Die toepassingsuitsluitingsmodel wat deur een kliënt gedokumenteer word, is 'n redelike verwysing vir hoe hierdie reëls beskryf word, al verskil die besonderhede tussen produkte. Lees joune, teken die identifiseerder aan wat jy gebruik het, en noteer die datum. Daardie rekord is wat 'n raaisel in 'n vyfminuutherstel verander die volgende keer wanneer die opstartprogram 'n opdatering uitstuur.

As die kliënt eenvoudig nie die grens kan uitdruk wat jy nodig het nie, is 'n goedgekeurde breër beleid beter as 'n hoop ongedokumenteerde uitsonderings. Breed en verstaanbaar klop smal en verkeerd, veral wanneer die smal weergawe is wat almal glo in plek is.

Verwante artikels