L'inici de sessió de Steam funciona, el joc no: reviseu cada camí

Inicieu Steam, entreu i tot sembla sa fins que el joc no troba cap sessió. Tracteu-ho com tres preguntes de xarxa separades i no com una de sola. La botiga i les pantalles del compte, la descàrrega de contingut i la sessió del joc poden arribar cadascuna a punts finals diferents per transports diferents. Feu aquestes comprovacions en ordre i atureu-vos a la primera que falli, perquè tot el que ve després és una conjectura.

Pas 1: confirmeu que l'inici de sessió és l'únic que ha funcionat

L'inici de sessió demostra que el compte ha arribat al servei d'identitat amb les credencials i qualsevol segon factor que el compte requereixi. No diu res sobre el lliurament de contingut ni diu res sobre l'esquema d'allotjament propi del joc. Anoteu quina de les tres operacions heu provat realment, perquè la gent sol informar d'un joc fallit després de provar només l'iniciador.

Llegiu el text de la fallada abans que la xarxa. Un joc que informa que no hi ha servidors disponibles us diu una cosa diferent d'un iniciador que no pot arribar a la botiga. Els dos errors vénen de capes diferents i poques vegades signifiquen el mateix. La distinció decideix si la propera comprovació tracta de la resolució de noms, d'UDP o d'un paràmetre de regió.

Anoteu el compte, la regió, el joc i l'hora. Sense aquests quatre valors, una comparació posterior és entre dues proves diferents que resulten compartir un nom.

Pas 2: anomeneu el transport de cada operació

El lliurament de contingut es comporta com una gran transferència HTTP i tolera la latència molt millor que la pèrdua. L'emparellament i les sessions dins del joc sovint fan servir UDP, on un camí que descarta paquets sembla un joc espatllat i no una descàrrega lenta. Aquests dos perfils fallen de manera diferent al mateix túnel, i per això una descàrrega ràpida no prediu una sessió funcional.

Comproveu les destinacions i els sòcols actius abans que la llista de ports del proveïdor. La llista diu què pot fer servir la plataforma, mentre que els sòcols diuen què fa aquest client ara mateix.

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

Si el procés del joc manté un sòcol UDP amb trànsit mentre el camí de transferència va bé, la fallada és a la pota UDP. Això estreny el problema a com el túnel tracta l'UDP i no al compte ni a la botiga.

Pas 3: comproveu la política d'inclusió abans de la llista de ports

Molts clients VPN apliquen la política per aplicació, per rang d'adreces o per família d'adreces en lloc de a tota la màquina. Un iniciador pot ser dins del túnel mentre un binari del joc llançat per separat és fora, i aleshores els dos no es posen d'acord sobre el món. La inclusió a nivell d'aplicació és el culpable habitual en portàtils de jocs amb un client de proveïdor instal·lat. Llegiu la política que realment està en vigor, no el perfil que vau desar el mes passat.

Mireu la taula de rutes i la interfície que posseeix la ruta per defecte. Una regla de túnel dividit basada en prefixos de destinació hi apareixerà, i una exclusió a nivell d'aplicació no. Val la pena conèixer aquesta diferència abans de canviar-ne cap.

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

Si el trànsit del joc surt per l'adaptador físic mentre la botiga va pel túnel, la política d'inclusió és la troballa. Cap excepció de port no arreglarà una decisió d'encaminament, i afegir-ne una només eixampla la superfície.

Pas 4: descarteu un camí SOCKS que no pot portar UDP

Tor proporciona un proxy SOCKS, i el suport de SOCKS a tot l'ecosistema és inconsistent pel que fa a UDP. El comportament documentat de Tor no implementa UDP ASSOCIATE, així que un joc el trànsit de sessió del qual sigui UDP no pot fer servir aquest camí per molt que el client s'hi adreci. Un navegador que funciona a través del proxy només demostra que els fluxos TCP del navegador funcionen.

Proveu l'afirmació i no la intenció. Si el joc encara informa d'una sessió no disponible mentre una prova només TCP a través del mateix proxy té èxit, el camí del proxy no porta el trànsit que el joc necessita.

Tracteu una VPN encaminada i un proxy SOCKS com eines diferents amb capacitats diferents. Canviar-ne una per l'altra és un canvi de disseny, no una preferència de configuració.

Contrasteu el registre amb l'acord

L'abastabilitat de la xarxa i el permís del compte són qüestions separades, i només la primera la respon un túnel funcional. La restricció tracta de la intenció darrere del proxying i no del protocol que heu triat. L'acord vigent limita el proxying d'IP la finalitat del qual és amagar on viu el titular del compte, així que un camí que funciona pot quedar fora dels termes que heu acceptat. Llegiu l'acord en lloc de tractar la connectivitat com una aprovació.

Per a una comparació honesta, canvieu una variable alhora i manteniu el mateix joc, regió de servidor, compte i operació. Després comproveu el resultat en les mateixes quatre operacions que vau anotar al principi.

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/

Quan el registre mostra que l'inici de sessió funciona, la descàrrega funciona i la sessió falla, la pregunta restant és sobre UDP al camí. Quan les tres funcionen, la queixa original era sobre una altra cosa, i el següent pas útil és el registre propi del joc i no el túnel. De qualsevol manera, la llista ha substituït una discussió per una observació concreta.