El teu túnel dividit exclou el llançador, no el joc

Afegiu el llançador a la llista d'exclusions, la baixada passa de lenta a ràpida i la partida continua acabant en un servidor llunyà. No hi ha res trencat. El llançador i el joc són dos processos amb dos conjunts de sockets, i excloure'n un no diu res de l'altre. La baixada es va accelerar perquè la baixada era el trànsit del llançador; la partida és la connexió d'una altra cosa, oberta per un executable que la vostra regla no ha vist mai.

Un instal·lador, molts processos

El programari de jocs modern és una petita constel·lació. Hi ha un client que us inicia la sessió, un actualitzador que baixa contingut, un llançador que engega el joc i un executable del joc que pot generar un segon procés per a l'anti-trampes o per a la capa de matchmaking. Cadascun pot mantenir les seves pròpies connexions cap a les seves pròpies destinacions.

Una regla d'exclusió normalment n'anomena un. Quin nomena depèn totalment de l'identificador que admet el client VPN, i aquesta és la part que els usuaris poques vegades comproven. Alguns clients fan coincidir una ruta d'executable, altres un identificador de paquet o bundle, i altres un nom de procés que dos binaris no relacionats poden compartir. Llegiu la regla abans de llegir la llista de processos, perquè la regla limita fins i tot què podeu expressar.

El símptoma, doncs, no és «el túnel dividit està trencat». És «la regla cobreix un procés que no és el que porta el trànsit que m'interessa», que és una afirmació molt més estreta i molt més reparable. Un cop ho dieu així, el següent pas deixa de ser una endevinalla.

Trobeu el procés que posseeix la connexió de la partida

Engegueu el joc, entreu en una partida i mireu qui posseeix les sockets en lloc de què hi ha a la pantalla. A Windows, la llista de processos més una consulta de sockets per procés ho responen en dues ordres:

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

La segona ordre imprimeix un identificador de procés, no un nom, així que ajunteu les dues sortides per identificador. La fila que busqueu és la que té l'adreça remota al servei del joc, i el procés que la posseeix és l'executable que la vostra regla ha de nomenar.

A Linux, la mateixa pregunta requereix una ordre per tipus de socket, i val la pena comprovar les dues, perquè la connexió d'una partida pot ser UDP mentre que tota la resta és TCP:

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

Si el joc s'executa en un contenidor o en una capa de compatibilitat, el procés que trobeu pot ser una shim en lloc del binari que heu instal·lat. En aquest cas, l'identificador que importa és el que veu el client, que pot ser la ruta de la shim, i cap quantitat d'edició del fitxer original no hi afectarà.

Feu coincidir l'identificador que admet el vostre client

Llegiu la documentació del client sobre la regla d'exclusió abans d'afegir res. Els tres models habituals es comporten de manera diferent, i un d'ells és una trampa.

Les regles de ruta són les més precises i les més fràgils. Una actualització del llançador que trasllada l'executable deixa la regla apuntant a un fitxer que ja no s'executa, i el símptoma torna sense que res canviï òbviament. Les regles de paquet ho sobreviuen, i també poden cobrir silenciosament processos auxiliars en què no havíeu pensat, cosa que és convenient o alarmant segons l'auxiliar.

Admeti el que admeti el client, no afegiu entrades per a cada executable que trobeu. Una llista muntada per assaig i error fins que una sessió va funcionar no es pot revisar, i acumularà silenciosament excepcions per a programari no relacionat. Nomenau el procés que heu trobat i anoteu per a què servia.

Proveu-ho a la partida, no a una baixada

La velocitat de baixada del llançador és la pitjor prova possible, perquè exercita exactament el procés que ja estava exclòs. Feu servir la cosa que fallava i comproveu la ruta en lloc de la pantalla de rendiment del propi joc:

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

La primera ordre necessita l'adreça a què va resoldre el servidor de la partida, que us poden donar el registre de connexions del joc o el vostre client. Si la ruta nomena la interfície física, la regla funciona. La segona mostra si existeix una sessió, cosa que separa «exclòs però el servidor està caigut» de «no exclòs».

Manteniu fixos la regió i la xarxa d'accés mentre proveu. Una partida que cau en un centre de dades diferent a cada intent produeix adreces diferents, i acabareu perseguint un objectiu mòbil en lloc de validar una regla. Dues execucions amb la mateixa adreça valen més que deu amb adreces diferents.

Torneu a comprovar-ho després de la propera actualització

Qualsevol regla basada en rutes té una vida útil mesurada en cicles de pedaços. Quan un mes més tard el joc deixa de respectar l'exclusió, la primera cosa que cal comprovar és si l'executable s'ha mogut, i la segona, si ha aparegut un procés auxiliar nou al seu costat.

El model d'exclusió d'aplicacions documentat per un client és una referència raonable de com es descriuen aquestes regles, tot i que els detalls varien entre productes. Llegiu el vostre, registreu l'identificador que heu fet servir i anoteu la data. Aquest registre és el que converteix un misteri en una correcció de cinc minuts la propera vegada que el llançador publiqui una actualització.

Si el client simplement no pot expressar el límit que necessiteu, una política més àmplia aprovada és millor que un munt d'excepcions no documentades. Ampli i entès supera estret i equivocat, sobretot quan la versió estreta és la que tothom creu que està en vigor.