Votre tunnel divisé exclut le lanceur, pas le jeu

Vous ajoutez le lanceur à la liste d'exclusion, le téléchargement passe de lent à rapide, et la partie atterrit toujours sur un serveur distant. Rien n'est cassé. Le lanceur et le jeu sont deux processus avec deux ensembles de sockets, et exclure l'un ne dit rien de l'autre. Le téléchargement s'est accéléré parce que le téléchargement était le trafic du lanceur ; la partie est la connexion de quelqu'un d'autre, ouverte par un exécutable que votre règle n'a jamais vu.

Un installateur, plusieurs processus

Le logiciel de jeu moderne est une petite constellation. Il y a un client qui vous connecte, un programme de mise à jour qui récupère du contenu, un lanceur qui démarre le jeu, et un exécutable de jeu qui peut lui-même créer un second processus pour l'anti-triche ou pour la couche d'appariement. Chacun d'eux peut conserver ses propres connexions vers ses propres destinations.

Une règle d'exclusion nomme généralement l'un d'eux. Lequel elle nomme dépend entièrement de l'identifiant pris en charge par le client VPN, et c'est la partie que les utilisateurs vérifient rarement. Certains clients font correspondre un chemin d'exécutable, d'autres un identifiant de paquet ou de bundle, et d'autres un nom de processus que deux binaires sans rapport peuvent partager. Lisez la règle avant de lire la liste des processus, car la règle limite même ce que vous pouvez exprimer.

Le symptôme n'est donc pas « le tunnel divisé est cassé ». C'est « la règle couvre un processus qui n'est pas celui qui transporte le trafic qui m'intéresse », ce qui est une affirmation bien plus étroite et bien plus réparable. Une fois que vous le dites ainsi, l'étape suivante cesse d'être une devinette.

Trouvez le processus qui possède la connexion de la partie

Démarrez le jeu, entrez dans une partie et regardez qui possède les sockets plutôt que ce qui est à l'écran. Sous Windows, la liste des processus plus une requête de sockets par processus y répondent en deux commandes :

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 seconde commande imprime un identifiant de processus, pas un nom, donc joignez les deux sorties par identifiant. La ligne que vous cherchez est celle dont l'adresse distante appartient au service du jeu, et son processus propriétaire est l'exécutable que votre règle doit nommer.

Sous Linux, la même question demande une commande par type de socket, et il vaut la peine de vérifier les deux, car la connexion d'une partie peut être en UDP alors que tout le reste est en TCP :

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

Si le jeu s'exécute dans un conteneur ou une couche de compatibilité, le processus que vous trouvez peut être un shim plutôt que le binaire que vous avez installé. Dans ce cas, l'identifiant qui compte est celui que voit le client, qui peut être le chemin du shim, et aucune modification du fichier d'origine n'y changera rien.

Faites correspondre l'identifiant pris en charge par votre client

Lisez la documentation du client sur la règle d'exclusion avant d'ajouter quoi que ce soit. Les trois modèles courants se comportent différemment, et l'un d'eux est un piège.

Les règles de chemin sont les plus précises et les plus fragiles. Une mise à jour du lanceur qui déplace l'exécutable laisse la règle pointer vers un fichier qui ne s'exécute plus, et le symptôme revient sans que rien ne change visiblement. Les règles de paquet y survivent, et elles peuvent aussi couvrir silencieusement des processus auxiliaires auxquels vous n'avez jamais pensé, ce qui est pratique ou inquiétant selon l'auxiliaire.

Quoi que prenne en charge le client, n'ajoutez pas d'entrées pour chaque exécutable que vous trouvez. Une liste assemblée par essais et erreurs jusqu'à ce qu'une session fonctionne n'est pas vérifiable, et elle accumulera silencieusement des exceptions pour des logiciels sans rapport. Nommez le processus que vous avez trouvé et notez à quoi il servait.

Testez sur la partie, pas sur un téléchargement

La vitesse de téléchargement du lanceur est le pire test possible, car elle exerce exactement le processus qui était déjà exclu. Utilisez ce qui échouait, et vérifiez le chemin plutôt que l'affichage de performance du jeu lui-même :

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

La première commande a besoin de l'adresse vers laquelle le serveur de la partie a résolu, que le journal de connexion du jeu ou votre client peut vous donner. Si la route nomme l'interface physique, la règle fonctionne. La seconde montre si une session existe, ce qui sépare « exclu mais le serveur est en panne » de « non exclu ».

Gardez la région et le réseau d'accès fixes pendant le test. Une partie qui atterrit dans un centre de données différent à chaque essai produit des adresses différentes, et vous finirez par poursuivre une cible mouvante au lieu de valider une règle. Deux exécutions avec la même adresse valent plus que dix avec des adresses différentes.

Revérifiez après la prochaine mise à jour

Toute règle basée sur un chemin a une durée de vie mesurée en cycles de correctifs. Quand le jeu cesse de respecter l'exclusion un mois plus tard, la première chose à vérifier est de savoir si l'exécutable a bougé, et la seconde si un nouveau processus auxiliaire est apparu à côté.

Le modèle d'exclusion d'applications documenté par un client est une référence raisonnable pour la façon dont ces règles sont décrites, même si les détails varient d'un produit à l'autre. Lisez le vôtre, notez l'identifiant utilisé et consignez la date. C'est cette note qui transforme un mystère en correction de cinq minutes la prochaine fois que le lanceur publie une mise à jour.

Si le client ne peut tout simplement pas exprimer la limite dont vous avez besoin, une politique plus large approuvée vaut mieux qu'un tas d'exceptions non documentées. Large et compris l'emporte sur étroit et faux, surtout quand la version étroite est ce que tout le monde croit en place.