O início de sessão no Steam funciona, o jogo não: verifica cada caminho

Inicia o Steam, inicia sessão, e tudo parece saudável até o jogo não encontrar uma sessão. Trata isso como três perguntas de rede separadas e não como uma. A loja e os ecrãs da conta, o download de conteúdo e a sessão do jogo podem cada um alcançar pontos finais diferentes através de transportes diferentes. Executa estas verificações por ordem e para na primeira que falhar, porque tudo o que vem depois é uma suposição.

Passo 1: confirma que o início de sessão foi a única coisa que funcionou

O início de sessão prova que a conta chegou ao serviço de identidade com as credenciais e qualquer segundo fator que a conta exija. Não diz nada sobre a entrega de conteúdo e não diz nada sobre o próprio esquema de alojamento do jogo. Anota qual das três operações testaste realmente, porque as pessoas costumam relatar um jogo falhado depois de testarem apenas o launcher.

Lê o texto da falha antes da rede. Um jogo que relata que não há servidores disponíveis diz-te algo diferente de um launcher que não chega à loja. Os dois erros vêm de camadas diferentes e raramente significam o mesmo. A distinção decide se a próxima verificação é sobre resolução de nomes, sobre UDP ou sobre uma definição de região.

Anota a conta, a região, o jogo e a hora. Sem esses quatro valores, uma comparação posterior é entre duas provas diferentes que por acaso partilham o mesmo nome.

Passo 2: nomeia o transporte de cada operação

A entrega de conteúdo comporta-se como uma grande transferência HTTP e tolera a latência muito melhor do que a perda. O matchmaking e as sessões dentro do jogo usam frequentemente UDP, onde um caminho que descarta pacotes parece um jogo avariado e não um download lento. Esses dois perfis falham de forma diferente no mesmo túnel, por isso um download rápido não prevê uma sessão funcional.

Verifica os destinos e os sockets ativos antes da lista de portas do fornecedor. A lista diz o que a plataforma pode usar, enquanto os sockets dizem o que este cliente está a fazer agora.

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 processo do jogo mantém um socket UDP com tráfego enquanto o caminho de transferência está bem, a falha está na parte UDP. Isso reduz o problema à forma como o túnel lida com UDP e não à conta ou à loja.

Passo 3: verifica a política de inclusão antes da lista de portas

Muitos clientes VPN aplicam a política por aplicação, por intervalo de endereços ou por família de endereços em vez de à máquina inteira. Um launcher pode estar dentro do túnel enquanto um binário do jogo lançado em separado está fora, e então os dois não concordam sobre o mundo. A inclusão ao nível da aplicação é o culpado habitual em portáteis de gaming com um cliente do fornecedor instalado. Lê a política que está realmente em vigor, não o perfil que guardaste no mês passado.

Olha para a tabela de rotas e para a interface que possui a rota predefinida. Uma regra de túnel dividido baseada em prefixos de destino aparecerá ali, e uma exclusão ao nível da aplicação não. Vale a pena conhecer essa diferença antes de alterar qualquer uma delas.

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

Se o tráfego do jogo sai pelo adaptador físico enquanto a loja passa pelo túnel, a política de inclusão é o achado. Nenhuma exceção de porta vai corrigir uma decisão de encaminhamento, e acrescentar uma só alarga a superfície.

Passo 4: exclui um caminho SOCKS que não consegue transportar UDP

O Tor fornece um proxy SOCKS, e o suporte de SOCKS em todo o ecossistema é inconsistente quanto a UDP. O comportamento documentado do Tor não implementa UDP ASSOCIATE, por isso um jogo cuja sessão use UDP não pode usar esse caminho, por muito que o cliente seja orientado para ele. Um navegador que funciona através do proxy só prova que os fluxos TCP do navegador funcionam.

Testa a afirmação e não a intenção. Se o jogo continua a relatar uma sessão indisponível enquanto uma prova apenas TCP através do mesmo proxy tem sucesso, o caminho do proxy não transporta o tráfego de que o jogo precisa.

Trata uma VPN encaminhada e um proxy SOCKS como ferramentas diferentes com capacidades diferentes. Trocar uma pela outra é uma alteração de conceção, não uma preferência de configuração.

Compara o registo com o acordo

A acessibilidade da rede e a permissão da conta são perguntas separadas, e só a primeira é respondida por um túnel funcional. A restrição diz respeito à intenção por trás do proxying e não ao protocolo que escolheste. O acordo em vigor limita o proxying de IP cujo objetivo é ocultar onde vive o titular da conta, por isso um caminho que funciona pode continuar fora dos termos que aceitaste. Lê o acordo em vez de tratar a conectividade como aprovação.

Para uma comparação honesta, muda uma variável de cada vez e mantém o mesmo jogo, região de servidor, conta e operação. Depois verifica o resultado nas mesmas quatro operações que anotaste no início.

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/

Quando o registo mostra que o início de sessão funciona, o download funciona e a sessão falha, a pergunta restante é sobre UDP no caminho. Quando as três funcionam, a queixa original era sobre outra coisa, e o próximo passo útil é o próprio registo do jogo e não o túnel. De qualquer forma, a lista substituiu uma discussão por uma observação concreta.