La connexion à Steam fonctionne, le jeu non : vérifiez chaque chemin

Lancez Steam, connectez-vous, et tout semble sain jusqu’à ce que le jeu ne trouve pas de session. Traitez cela comme trois questions réseau distinctes plutôt qu’une. La boutique et les écrans de compte, le téléchargement de contenu et la session de jeu peuvent chacun atteindre des points de terminaison différents via des transports différents. Exécutez ces vérifications dans l’ordre et arrêtez-vous à la première qui échoue, car tout ce qui suit est une supposition.

Étape 1 : confirmez que la connexion est la seule chose qui a fonctionné

La connexion prouve que le compte a atteint le service d’identité avec les identifiants et tout second facteur que le compte exige. Elle ne dit rien sur la distribution de contenu et rien sur l’organisation d’hébergement propre au jeu. Notez laquelle des trois opérations vous avez réellement testée, car les gens signalent couramment un jeu défaillant après n’avoir testé que le lanceur.

Lisez le texte de l’échec avant le réseau. Un jeu qui signale qu’aucun serveur n’est disponible vous dit autre chose qu’un lanceur qui n’atteint pas la boutique. Les deux erreurs viennent de couches différentes et signifient rarement la même chose. La distinction décide si la prochaine vérification porte sur la résolution de noms, sur UDP ou sur un réglage de région.

Notez le compte, la région, le jeu et l’heure. Sans ces quatre valeurs, une comparaison ultérieure se fait entre deux tests différents qui partagent par hasard le même nom.

Étape 2 : nommez le transport de chaque opération

La distribution de contenu se comporte comme un gros transfert HTTP et tolère bien mieux la latence que la perte. Le matchmaking et les sessions en jeu utilisent souvent UDP, où un chemin qui perd des paquets ressemble à un jeu cassé plutôt qu’à un téléchargement lent. Ces deux profils échouent différemment sur le même tunnel, c’est pourquoi un téléchargement rapide ne prédit pas une session fonctionnelle.

Vérifiez les destinations et les sockets actives plutôt que d’abord la liste de ports du fournisseur. La liste indique ce que la plateforme peut utiliser, tandis que les sockets indiquent ce que ce client fait maintenant.

nslookup api.steampowered.com
ss -uanp | head -20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://store.steampowered.com/

Si le processus du jeu détient une socket UDP avec du trafic alors que le chemin de transfert est bon, la défaillance est dans la jambe UDP. Cela réduit le problème à la façon dont le tunnel gère UDP, et non au compte ou à la boutique.

Étape 3 : vérifiez la politique d’inclusion avant la liste de ports

De nombreux clients VPN appliquent la politique par application, par plage d’adresses ou par famille d’adresses plutôt qu’à la machine entière. Un lanceur peut être dans le tunnel tandis qu’un binaire de jeu lancé séparément est dehors, et les deux ne sont alors pas d’accord sur le monde. L’inclusion au niveau de l’application est le coupable habituel sur les ordinateurs portables de jeu avec un client de fournisseur installé. Lisez la politique réellement en vigueur, pas le profil que vous avez enregistré le mois dernier.

Regardez la table de routage et l’interface qui possède la route par défaut. Une règle de tunnel divisé basée sur des préfixes de destination y apparaîtra, et une exclusion au niveau de l’application non. Cette différence vaut la peine d’être connue avant de modifier l’une ou l’autre.

ip route show default
ip -brief addr
Get-NetAdapter | Select-Object Name, Status, InterfaceDescription

Si le trafic du jeu sort par l’adaptateur physique tandis que la boutique passe par le tunnel, la politique d’inclusion est le constat. Aucune exception de port ne corrigera une décision de routage, et en ajouter une ne fait qu’élargir la surface.

Étape 4 : écartez un chemin SOCKS qui ne peut pas transporter UDP

Tor fournit un proxy SOCKS, et la prise en charge de SOCKS dans l’écosystème est incohérente concernant UDP. Le comportement documenté de Tor n’implémente pas UDP ASSOCIATE, donc un jeu dont le trafic de session est UDP ne peut pas utiliser ce chemin, quelle que soit la façon dont le client y est dirigé. Un navigateur qui fonctionne via le proxy prouve seulement que les flux TCP du navigateur fonctionnent.

Testez l’affirmation plutôt que l’intention. Si le jeu signale encore une session indisponible alors qu’un test uniquement TCP via le même proxy réussit, le chemin du proxy ne transporte pas le trafic dont le jeu a besoin.

Traitez un VPN routé et un proxy SOCKS comme des outils différents aux capacités différentes. Échanger l’un contre l’autre est un changement de conception, pas une préférence de configuration.

Confrontez le constat à l’accord

L’accessibilité du réseau et l’autorisation du compte sont deux questions distinctes, et seule la première trouve réponse dans un tunnel fonctionnel. La restriction porte sur l’intention derrière le proxying et non sur le protocole choisi. L’accord en vigueur limite le proxying IP dont le but est de dissimuler où vit le titulaire du compte, donc un chemin qui fonctionne peut encore se situer hors des conditions acceptées. Lisez l’accord au lieu de considérer la connectivité comme une approbation.

Pour une comparaison honnête, ne changez qu’une variable à la fois et gardez le même jeu, la même région de serveur, le même compte et la même opération. Vérifiez ensuite le résultat sur les mêmes quatre opérations notées au départ.

tracert -h 12 store.steampowered.com
ss -uanp | grep -i -E 'game|steam'
curl -sS -o /dev/null -w '%{remote_ip} %{time_connect}\n' https://store.steampowered.com/

Quand le constat montre que la connexion fonctionne, que le téléchargement fonctionne et que la session échoue, la question restante porte sur UDP sur le chemin. Quand les trois fonctionnent, la plainte initiale portait sur autre chose, et la prochaine étape utile est le journal du jeu lui-même plutôt que le tunnel. Dans un cas comme dans l’autre, la liste a remplacé une dispute par une observation précise.