El inicio de sesión de Steam funciona, el juego no: revisa cada ruta

Inicia Steam, inicia sesión y todo parece sano hasta que el juego no encuentra una sesión. Trata eso como tres preguntas de red separadas y no como una. La tienda y las pantallas de la cuenta, la descarga de contenido y la sesión del juego pueden alcanzar cada una extremos distintos por transportes distintos. Ejecuta estas comprobaciones en orden y detente en la primera que falle, porque todo lo que viene después es una conjetura.

Paso 1: confirma que el inicio de sesión es lo único que funcionó

El inicio de sesión demuestra que la cuenta llegó al servicio de identidad con las credenciales y cualquier segundo factor que la cuenta exija. No dice nada sobre la entrega de contenido y no dice nada sobre el propio esquema de alojamiento del juego. Anota cuál de las tres operaciones probaste realmente, porque la gente suele informar de un juego fallido después de probar solo el lanzador.

Lee el texto del fallo antes que la red. Un juego que informa que no hay servidores disponibles te dice algo distinto de un lanzador que no llega a la tienda. Los dos errores vienen de capas diferentes y rara vez significan lo mismo. La distinción decide si la siguiente comprobación trata de resolución de nombres, de UDP o de un ajuste de región.

Anota la cuenta, la región, el juego y la hora. Sin esos cuatro valores, una comparación posterior es entre dos pruebas distintas que casualmente comparten un nombre.

Paso 2: nombra el transporte de cada operación

La entrega de contenido se comporta como una gran transferencia HTTP y tolera la latencia mucho mejor de lo que tolera la pérdida. El emparejamiento y las sesiones dentro del juego suelen usar UDP, donde una ruta que descarta paquetes parece un juego roto y no una descarga lenta. Esos dos perfiles fallan de forma distinta en el mismo túnel, por eso una descarga rápida no predice una sesión funcional.

Comprueba los destinos y los sockets activos antes que la lista de puertos del proveedor. La lista dice qué puede usar la plataforma, mientras que los sockets dicen qué está haciendo este cliente ahora mismo.

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 proceso del juego mantiene un socket UDP con tráfico mientras la ruta de transferencia está bien, el fallo está en la pata UDP. Eso reduce el problema a cómo maneja el túnel el UDP y no a la cuenta ni a la tienda.

Paso 3: comprueba la política de inclusión antes de la lista de puertos

Muchos clientes VPN aplican la política por aplicación, por rango de direcciones o por familia de direcciones en lugar de a toda la máquina. Un lanzador puede estar dentro del túnel mientras un binario del juego lanzado por separado está fuera, y entonces los dos no se ponen de acuerdo sobre el mundo. La inclusión a nivel de aplicación es el culpable habitual en portátiles gaming con un cliente del proveedor instalado. Lee la política que realmente está en vigor, no el perfil que guardaste el mes pasado.

Mira la tabla de rutas y la interfaz que posee la ruta predeterminada. Una regla de túnel dividido basada en prefijos de destino aparecerá allí, y una exclusión a nivel de aplicación no. Esa diferencia merece conocerse antes de cambiar cualquiera de las dos.

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

Si el tráfico del juego sale por el adaptador físico mientras la tienda va por el túnel, la política de inclusión es el hallazgo. Ninguna excepción de puerto arreglará una decisión de enrutamiento, y añadir una solo amplía la superficie.

Paso 4: descarta una ruta SOCKS que no puede transportar UDP

Tor proporciona un proxy SOCKS, y el soporte de SOCKS en todo el ecosistema es inconsistente en cuanto a UDP. El comportamiento documentado de Tor no implementa UDP ASSOCIATE, así que un juego cuya sesión use UDP no puede usar esa ruta por mucho que el cliente se oriente hacia ella. Un navegador que funciona a través del proxy solo demuestra que los flujos TCP del navegador funcionan.

Prueba la afirmación y no la intención. Si el juego sigue informando de una sesión no disponible mientras una prueba solo TCP a través del mismo proxy tiene éxito, la ruta del proxy no transporta el tráfico que el juego necesita.

Trata una VPN enrutada y un proxy SOCKS como herramientas distintas con capacidades distintas. Cambiar una por otra es un cambio de diseño, no una preferencia de configuración.

Contrasta el registro con el acuerdo

La accesibilidad de la red y el permiso de la cuenta son preguntas separadas, y solo la primera la responde un túnel funcional. La restricción tiene que ver con la intención detrás del proxying y no con el protocolo que elegiste. El acuerdo vigente limita el proxying de IP cuya finalidad es ocultar dónde vive el titular de la cuenta, así que una ruta que funciona puede seguir fuera de los términos que aceptaste. Lee el acuerdo en lugar de tratar la conectividad como aprobación.

Para una comparación honesta, cambia una variable a la vez y mantén el mismo juego, región de servidor, cuenta y operación. Luego comprueba el resultado en las mismas cuatro operaciones que anotaste al principio.

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/

Cuando el registro muestra que el inicio de sesión funciona, la descarga funciona y la sesión falla, la pregunta restante es sobre UDP en la ruta. Cuando las tres funcionan, la queja original era sobre otra cosa, y el siguiente paso útil es el propio registro del juego y no el túnel. En cualquier caso, la lista ha sustituido una discusión por una observación concreta.