O inicio de sesión de Steam funciona, o xogo non: revisa cada ruta

Inicia Steam, inicia sesión e todo parece san ata que o xogo non atopa unha sesión. Trata iso como tres preguntas de rede separadas e non como unha. A tenda e as pantallas da conta, a descarga de contido e a sesión do xogo poden alcanzar cada unha extremos distintos por transportes distintos. Executa estas comprobacións en orde e detente na primeira que falle, porque todo o que vén despois é unha conxectura.

Paso 1: confirma que o inicio de sesión é o único que funcionou

O inicio de sesión demostra que a conta chegou ao servizo de identidade coas credenciais e calquera segundo factor que a conta esixa. Non di nada sobre a entrega de contido e non di nada sobre o propio esquema de aloxamento do xogo. Anota cal das tres operacións probaches realmente, porque a xente adoita informar dun xogo fallido despois de probar só o lanzador.

Le o texto do fallo antes que a rede. Un xogo que informa de que non hai servidores dispoñibles diche algo distinto dun lanzador que non chega á tenda. Os dous erros veñen de capas diferentes e raramente significan o mesmo. A distinción decide se a seguinte comprobación trata de resolución de nomes, de UDP ou dun axuste de rexión.

Anota a conta, a rexión, o xogo e a hora. Sen eses catro valores, unha comparación posterior é entre dúas probas distintas que casualmente comparten un nome.

Paso 2: nomea o transporte de cada operación

A entrega de contido compórtase como unha gran transferencia HTTP e tolera a latencia moito mellor do que tolera a perda. O emparellamento e as sesións dentro do xogo adoitan usar UDP, onde unha ruta que descarta paquetes parece un xogo roto e non unha descarga lenta. Eses dous perfís fallan de forma distinta no mesmo túnel, por iso unha descarga rápida non predí unha sesión funcional.

Comproba os destinos e os sockets activos antes que a lista de portos do provedor. A lista di que pode usar a plataforma, mentres que os sockets din que está a facer este cliente agora mesmo.

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

Se o proceso do xogo mantén un socket UDP con tráfico mentres a ruta de transferencia está ben, o fallo está na pata UDP. Iso reduce o problema a como xestiona o túnel o UDP e non á conta nin á tenda.

Paso 3: comproba a política de inclusión antes da lista de portos

Moitos clientes VPN aplican a política por aplicación, por rango de enderezos ou por familia de enderezos en lugar de a toda a máquina. Un lanzador pode estar dentro do túnel mentres un binario do xogo lanzado por separado está fóra, e entón os dous non se poñen de acordo sobre o mundo. A inclusión a nivel de aplicación é o culpable habitual en portátiles gaming cun cliente do provedor instalado. Le a política que realmente está en vigor, non o perfil que gardaches o mes pasado.

Mira a táboa de rutas e a interface que posúe a ruta predeterminada. Unha regra de túnel dividido baseada en prefixos de destino aparecerá alí, e unha exclusión a nivel de aplicación non. Esa diferenza paga a pena coñecela antes de cambiar calquera das dúas.

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

Se o tráfico do xogo sae polo adaptador físico mentres a tenda vai polo túnel, a política de inclusión é o achado. Ningunha excepción de porto arranxará unha decisión de encamiñamento, e engadir unha só amplía a superficie.

Paso 4: descarta unha ruta SOCKS que non pode transportar UDP

Tor proporciona un proxy SOCKS, e o soporte de SOCKS en todo o ecosistema é inconsistente en canto a UDP. O comportamento documentado de Tor non implementa UDP ASSOCIATE, así que un xogo cuxa sesión use UDP non pode usar esa ruta por moito que o cliente se oriente cara a ela. Un navegador que funciona a través do proxy só demostra que os fluxos TCP do navegador funcionan.

Proba a afirmación e non a intención. Se o xogo segue informando dunha sesión non dispoñible mentres unha proba só TCP a través do mesmo proxy ten éxito, a ruta do proxy non transporta o tráfico que o xogo necesita.

Trata unha VPN encamiñada e un proxy SOCKS como ferramentas distintas con capacidades distintas. Cambiar unha pola outra é un cambio de deseño, non unha preferencia de configuración.

Contrasta o rexistro co acordo

A accesibilidade da rede e o permiso da conta son preguntas separadas, e só a primeira a responde un túnel funcional. A restrición ten que ver coa intención detrás do proxying e non co protocolo que escolliches. O acordo vixente limita o proxying de IP cuxa finalidade é ocultar onde vive o titular da conta, así que unha ruta que funciona pode seguir fóra dos termos que aceptaches. Le o acordo en lugar de tratar a conectividade como aprobación.

Para unha comparación honesta, cambia unha variable cada vez e mantén o mesmo xogo, rexión de servidor, conta e operación. Despois comproba o resultado nas mesmas catro operacións que anotaches ao 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/

Cando o rexistro mostra que o inicio de sesión funciona, a descarga funciona e a sesión falla, a pregunta restante é sobre UDP na ruta. Cando as tres funcionan, a queixa orixinal era sobre outra cousa, e o seguinte paso útil é o propio rexistro do xogo e non o túnel. En calquera caso, a lista substituíu unha discusión por unha observación concreta.