Tunelul tău divizat exclude lansatorul, nu jocul

Adaugi lansatorul în lista de excluderi, descărcarea sare de la lentă la rapidă, iar meciul ajunge tot pe un server îndepărtat. Nimic nu este stricat. Lansatorul și jocul sunt două procese cu două seturi de socketuri, iar excluderea unuia nu spune nimic despre celălalt. Descărcarea a devenit mai rapidă pentru că descărcarea era traficul lansatorului; meciul este conexiunea altcuiva, deschisă de un executabil pe care regula ta nu l-a văzut niciodată.

Un instalator, multe procese

Software-ul modern pentru jocuri este o mică constelație. Există un client care te autentifică, un actualizator care descarcă conținut, un lansator care pornește jocul și un executabil al jocului care poate genera el însuși un al doilea proces pentru anti-cheat sau pentru stratul de matchmaking. Fiecare dintre ele poate păstra propriile conexiuni către propriile destinații.

O regulă de excludere numește de obicei unul dintre ele. Pe care îl numește depinde în întregime de identificatorul pe care îl acceptă clientul VPN, iar aceasta este partea pe care utilizatorii o verifică rar. Unii clienți potrivesc o cale de executabil, alții un identificator de pachet sau bundle, iar alții un nume de proces pe care două binare neînrudite îl pot împărți. Citește regula înainte de lista de procese, pentru că regula limitează chiar și ceea ce poți exprima.

Așadar simptomul nu este „tunelul divizat este stricat”. Este „regula acoperă un proces care nu este cel care transportă traficul de care îmi pasă”, ceea ce este o afirmație mult mai îngustă și mult mai reparabilă. Odată ce spui asta așa, pasul următor încetează să mai fie o presupunere.

Găsește procesul care deține conexiunea meciului

Pornește jocul, intră într-un meci și uită-te cine deține socketurile, nu ce apare pe ecran. În Windows, lista de procese plus o interogare de socketuri pentru fiecare proces răspund la asta cu două comenzi:

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

A doua comandă afișează un ID de proces, nu un nume, așa că unește cele două ieșiri după ID. Rândul pe care îl cauți este cel al cărui adresă la distanță aparține serviciului jocului, iar procesul care îl deține este executabilul pe care regula ta trebuie să îl numească.

În Linux, aceeași întrebare necesită o comandă pentru fiecare tip de socket și merită verificate ambele, pentru că o conexiune de meci poate fi UDP în timp ce tot restul este TCP:

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

Dacă jocul rulează într-un container sau într-un strat de compatibilitate, procesul găsit poate fi un shim, nu binarul pe care l-ai instalat. În acest caz, identificatorul important este cel pe care îl vede clientul, care poate fi calea shimului, iar nicio editare a fișierului original nu va afecta asta.

Potrivește identificatorul acceptat de clientul tău

Citește documentația clientului pentru regula de excludere înainte de a adăuga ceva. Cele trei modele obișnuite se comportă diferit, iar unul dintre ele este o capcană.

Regulile de cale sunt cele mai precise și cele mai fragile. O actualizare a lansatorului care mută executabilul lasă regula să indice un fișier care nu mai rulează, iar simptomul revine fără ca ceva să se schimbe vizibil. Regulile de pachet rezistă la asta și pot acoperi în tăcere procese auxiliare la care nu te-ai gândit niciodată, ceea ce este fie convenabil, fie alarmant, în funcție de auxiliar.

Indiferent ce acceptă clientul, nu adăuga intrări pentru fiecare executabil pe care îl găsești. O listă alcătuită prin încercări și erori până când o sesiune a funcționat nu poate fi revizuită și va acumula în tăcere excepții pentru software neînrudit. Numește procesul găsit și notează pentru ce servea.

Testează pe meci, nu pe o descărcare

Viteza de descărcare a lansatorului este cel mai prost test posibil, pentru că exersează exact procesul care era deja exclus. Folosește lucrul care eșua și verifică ruta, nu afișajul de performanță al jocului:

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

Prima comandă are nevoie de adresa la care a rezolvat serverul meciului, pe care o poate da jurnalul de conexiuni al jocului sau clientul tău. Dacă ruta numește interfața fizică, regula funcționează. A doua arată dacă există o sesiune, ceea ce separă „exclus, dar serverul este picat” de „neexclus”.

Păstrează regiunea și rețeaua de acces fixe în timpul testului. Un meci care ajunge într-un centru de date diferit la fiecare încercare produce adrese diferite, iar tu vei sfârși prin a urmări o țintă mobilă în loc să validezi o regulă. Două rulări cu aceeași adresă valorează mai mult decât zece cu adrese diferite.

Verifică din nou după următoarea actualizare

Orice regulă bazată pe cale are o durată de valabilitate măsurată în cicluri de patch. Când jocul încetează să respecte excluderea o lună mai târziu, primul lucru de verificat este dacă executabilul s-a mutat, iar al doilea dacă a apărut un proces auxiliar nou lângă el.

Modelul excluderii aplicațiilor documentat de un client este o referință rezonabilă pentru modul în care sunt descrise aceste reguli, deși detaliile diferă între produse. Citește-l pe al tău, înregistrează identificatorul folosit și notează data. Acea înregistrare este ce transformă un mister într-o reparație de cinci minute data viitoare când lansatorul publică o actualizare.

Dacă clientul pur și simplu nu poate exprima limita de care ai nevoie, o politică mai largă aprobată este mai bună decât o grămadă de excepții nedocumentate. Larg și înțeles bate îngust și greșit, mai ales când versiunea îngustă este ceea ce toată lumea crede că este în vigoare.