Porque é que o teu jogo LAN desaparece antes de adicionares uma VPN

Um grupo de pessoas instala um jogo, liga-se à mesma rede e vê uma lista de servidores vazia. O reflexo é culpar a rede e procurar um túnel, mas o jogo pode nunca ter enviado um pacote que um túnel pudesse transportar. Antes de qualquer VPN entrar em cena, descobre qual das três coisas a edição faz realmente quando alguém clica em multijogador.

As três não são intercambiáveis. Uma usa tráfego local direto, outra pergunta a um serviço quem mais está a jogar, e outra recusa arrancar sem uma conta. Um túnel pode ajudar com a primeira, é irrelevante para a segunda e não resolve a terceira. Esta ordem importa, porque as três podem produzir a mesma lista vazia com três correções diferentes.

O que o jogo verifica antes de listar um anfitrião

A maioria dos menus multijogador faz várias coisas em sequência: confirma a conta com sessão iniciada, verifica os direitos da edição, consulta um backend para lobbies ou amigos, e só depois olha para a rede local. Qualquer passo pode falhar em silêncio, e a interface mostra normalmente a mesma lista vazia em ambos os casos. É por isso que «a LAN está avariada» é um diagnóstico que não podes fazer só pelo ecrã. Um erro de backend, um direito expirado e uma sub-rede isolada são indistinguíveis no ecrã do lobby, e só um deles é sequer um problema de rede.

Lê a documentação da própria edição antes de alterar as definições de rede. As remasterizações removem rotineiramente a entrada direta por IP, substituem a deteção LAN por um lobby alojado ou exigem uma conta de plataforma que o lançamento original nunca precisou. A página de suporte da atual Age of Empires II: Definitive Edition, por exemplo, descreve um lobby alojado nos servidores do jogo onde escolhes visibilidade, palavra-passe e região; é um fluxo de aplicação a verificar para essa edição, não uma prova sobre qualquer lançamento anterior.

Anota o número de compilação e também o nome da edição. Um patch pode passar um jogo de um modelo para outro, e instruções escritas para a compilação de lançamento podem descrever um menu que já não existe.

Os pacotes de deteção morrem no primeiro router

O jogo LAN direto depende normalmente de broadcast ou multicast: o anfitrião anuncia-se para um endereço de toda a sub-rede, e os clientes ouvem esse anúncio. Estes pacotes não são encaminháveis por conceção, por isso um router entre as duas máquinas descarta-os mesmo quando o tráfego unicast passaria. Dois dispositivos no mesmo switch veem-se; os mesmos dois dispositivos em VLAN diferentes, ou numa rede de convidados com isolamento de clientes, não se veem. As consolas e os telefones seguem normalmente o mesmo padrão com o seu próprio protocolo de deteção, e é por isso que a plataforma importa tanto como o jogo.

É daqui que vem a maioria dos relatos «mesmo Wi-Fi, sem servidores». Um SSID de convidados com isolamento ativo, um sistema mesh que coloca a consola num segmento separado, ou um perfil de firewall que trata a sub-rede local como pública vão quebrar a deteção, mantendo o acesso normal à internet a funcionar. Verifica a definição de isolamento de clientes e a máscara de sub-rede antes de assumires que o jogo tem culpa.

Um serviço de lobby não é um caminho de rede

Quando o jogo usa um lobby alojado, a lista de partidas vem dos servidores do operador, não da tua sub-rede. Uma VPN altera o caminho que os teus pacotes percorrem até esses servidores, mas não altera quais lobbies o serviço te mostra, em que região a partida está alojada, ou se a tua conta tem direito a entrar. São respostas que o backend dá, e nenhuma quantidade de encaminhamento as muda.

Nesse modelo, um túnel é no melhor caso uma variável de latência e no pior um problema de geodeteção, porque o serviço vê o endereço de saída em vez do teu endereço de rua. A mesma lógica aplica-se a convites de amigos e sistemas de grupo. São funcionalidades ao nível da conta mediadas pela plataforma, e é por isso que dois jogadores na mesma LAN podem não se ver num lobby, embora ambos consigam entrar na partida de um desconhecido.

O que um túnel pode reconstruir e o que não pode

Um túnel é útil quando os jogadores estão em locais diferentes e o jogo suporta entrada direta por endereço. Um túnel encaminhado transporta tráfego unicast entre os dois locais; um túnel em ponte, ou uma sobreposição que apresenta um segmento Ethernet virtual, também pode transportar a deteção broadcast de que o jogo LAN direto depende. É esta a distinção a compreender: o encaminhamento move pacotes entre sub-redes, a ponte faz dois locais parecerem uma só sub-rede.

O que um túnel não pode fazer é acrescentar um modo multijogador que a aplicação não implementa. Se a edição removeu a entrada direta, um segmento LAN virtual não a repõe. Se o lobby exige uma conta, um túnel não satisfaz a verificação. E se as duas máquinas estiverem atrás do mesmo NAT com isolamento entre elas, uma sobreposição pode contornar o isolamento, mas isso é também um contorno de políticas, uma conversa a ter com quem gere a rede.

Testa o caminho que o jogo usa de facto

Começa com um anfitrião e um cliente na mesma sub-rede, isolamento desligado e sem túnel. Se isso funcionar, o jogo e a edição suportam o que estás a tentar fazer, e qualquer falha posterior é um problema de caminho. Se falhar aí, o túnel nunca foi a resposta.

Depois regista o que o manual diz sobre o método de entrada, a porta ou o mecanismo de deteção, e qualquer requisito de conta. Muda uma variável de cada vez: primeiro a sub-rede, depois o segmento, depois o túnel. Guarda o endereço do anfitrião e o caminho exato do menu para que a sessão seguinte possa repetir o teste em vez da discussão.

Define a versão, quem aloja, como as pessoas entram e que conta ou subscrição a sessão precisa, e escreve isso antes da data. Termina mais discussões do que qualquer túnel e deixa registo do que foi testado.