Il tuo tunnel diviso esclude il launcher, non il gioco

Aggiungi il launcher alla lista di esclusione, il download passa da lento a veloce, e la partita finisce comunque su un server lontano. Niente è rotto. Il launcher e il gioco sono due processi con due insiemi di socket, ed escluderne uno non dice nulla sull'altro. Il download è diventato più veloce perché il download era il traffico del launcher; la partita è la connessione di qualcun altro, aperta da un eseguibile che la tua regola non ha mai visto.

Un installer, molti processi

Il software di gioco moderno è una piccola costellazione. C'è un client che ti fa accedere, un aggiornatore che scarica contenuti, un launcher che avvia il gioco e un eseguibile del gioco che può esso stesso generare un secondo processo per l'anti-cheat o per il livello di matchmaking. Ognuno di questi può mantenere le proprie connessioni verso le proprie destinazioni.

Una regola di esclusione di solito ne nomina uno. Quale nomini dipende interamente dall'identificatore supportato dal client VPN, ed è la parte che gli utenti controllano raramente. Alcuni client abbinano un percorso di eseguibile, altri un identificatore di pacchetto o bundle, e altri un nome di processo che due binari non correlati possono condividere. Leggi la regola prima della lista dei processi, perché la regola limita persino ciò che puoi esprimere.

Il sintomo quindi non è «il tunnel diviso è rotto». È «la regola copre un processo che non è quello che trasporta il traffico che mi interessa», che è un'affermazione molto più ristretta e molto più riparabile. Una volta che lo dici così, il passo successivo smette di essere un'ipotesi.

Trova il processo che possiede la connessione della partita

Avvia il gioco, entra in una partita e guarda chi possiede i socket invece di ciò che c'è sullo schermo. Su Windows la lista dei processi più una query dei socket per processo rispondono con due comandi:

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

Il secondo comando stampa un ID di processo, non un nome, quindi unisci i due output per ID. La riga che cerchi è quella il cui indirizzo remoto appartiene al servizio del gioco, e il processo che la possiede è l'eseguibile che la tua regola deve nominare.

Su Linux la stessa domanda richiede un comando per tipo di socket, e vale la pena controllarli entrambi, perché la connessione di una partita può essere UDP mentre tutto il resto è TCP:

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

Se il gioco gira in un container o in uno strato di compatibilità, il processo che trovi può essere uno shim invece del binario che hai installato. In quel caso l'identificatore che conta è quello che vede il client, che può essere il percorso dello shim, e nessuna modifica al file originale lo influenzerà.

Abbina l'identificatore supportato dal tuo client

Leggi la documentazione del client sulla regola di esclusione prima di aggiungere qualsiasi cosa. I tre modelli comuni si comportano diversamente, e uno di essi è una trappola.

Le regole di percorso sono le più precise e le più fragili. Un aggiornamento del launcher che sposta l'eseguibile lascia la regola puntata a un file che non viene più eseguito, e il sintomo ritorna senza che nulla cambi in modo evidente. Le regole di pacchetto sopravvivono a questo, e possono anche coprire silenziosamente processi ausiliari a cui non hai mai pensato, il che è comodo o allarmante a seconda dell'ausiliario.

Qualunque cosa supporti il client, non aggiungere voci per ogni eseguibile che trovi. Un elenco messo insieme per tentativi ed errori finché una sessione ha funzionato non è verificabile, e accumulerà silenziosamente eccezioni per software non correlato. Nomina il processo che hai trovato e annota a cosa serviva.

Testa sulla partita, non su un download

La velocità di download del launcher è il peggior test possibile, perché esercita esattamente il processo che era già escluso. Usa ciò che falliva, e controlla il percorso invece del display delle prestazioni del gioco stesso:

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

Il primo comando ha bisogno dell'indirizzo verso cui il server della partita ha risolto, che il registro delle connessioni del gioco o il tuo client possono darti. Se la rotta nomina l'interfaccia fisica, la regola funziona. Il secondo mostra se esiste una sessione, il che separa «escluso ma il server è giù» da «non escluso».

Mantieni fisse la regione e la rete di accesso durante il test. Una partita che atterra in un data center diverso a ogni tentativo produce indirizzi diversi, e finirai per inseguire un bersaglio mobile invece di validare una regola. Due esecuzioni con lo stesso indirizzo valgono più di dieci con indirizzi diversi.

Ricontrolla dopo il prossimo aggiornamento

Ogni regola basata sul percorso ha una durata misurata in cicli di patch. Quando il gioco smette di rispettare l'esclusione un mese dopo, la prima cosa da controllare è se l'eseguibile si è spostato, e la seconda è se è apparso accanto ad esso un nuovo processo ausiliario.

Il modello di esclusione delle applicazioni documentato da un client è un riferimento ragionevole per come queste regole vengono descritte, anche se i dettagli variano tra i prodotti. Leggi il tuo, registra l'identificatore che hai usato e annota la data. È quella nota che trasforma un mistero in una correzione di cinque minuti la prossima volta che il launcher pubblica un aggiornamento.

Se il client semplicemente non riesce a esprimere il confine che ti serve, una politica più ampia approvata è meglio di un mucchio di eccezioni non documentate. Ampio e compreso batte stretto e sbagliato, soprattutto quando la versione stretta è quella che tutti credono in vigore.