Por que o teu xogo de LAN desaparece antes de engadir unha VPN

Un grupo de persoas instala un xogo, conéctase á mesma rede e ve unha lista de servidores baleira. O reflexo é culpar a rede e buscar un túnel, pero pode que o xogo nunca enviase un paquete que un túnel puidese transportar. Antes de que entre en escena calquera VPN, averigua cal de tres cousas fai realmente a edición cando alguén preme multixogador.

As tres non son intercambiables. Unha usa tráfico local directo, outra pregunta a un servizo quen máis está xogando e unha terceira négase a arrincar sen conta. Un túnel pode axudar coa primeira, é irrelevante para a segunda e non pode arranxar a terceira. Esa orde importa, porque as tres poden producir a mesma lista baleira con tres solucións distintas.

Que comproba o xogo antes de listar un anfitrión

A maioría dos menús multixogador fan varias cousas en secuencia: confirman a conta con sesión iniciada, comproban os dereitos da edición, consultan un backend por salas ou amigos e só despois miran a rede local. Calquera paso pode fallar en silencio, e a interface adoita mostrar a mesma lista baleira en ambos os casos. Por iso “a LAN está rota” é un diagnóstico que non podes facer só desde a pantalla. Un erro do backend, un dereito caducado e unha subrede illada son indistinguibles desde a pantalla da sala, e só un deles é sequera un problema de rede.

Le a documentación da propia edición antes de cambiar axustes de rede. Os remasterizados adoitan abandonar a unión directa por IP, substituír o descubrimento na LAN por unha sala aloxada ou esixir unha conta de plataforma que o lanzamento orixinal nunca necesitou. A páxina de soporte da actual Age of Empires II: Definitive Edition, por exemplo, explica unha sala aloxada nos servidores do xogo onde elixes visibilidade, contrasinal e rexión; iso é un fluxo de traballo da aplicación que hai que verificar para esa edición, non unha proba sobre ningún lanzamento anterior.

Fíxate no número de compilación ademais do nome da edición. Un parche pode mover un xogo dun modelo a outro, e as instrucións escritas para a compilación de lanzamento poden describir un menú que xa non existe.

Os paquetes de descubrimento morren no primeiro router

O xogo directo por LAN adoita depender de broadcast ou multicast: o anfitrión anúnciase nun enderezo de toda a subrede e os clientes escoitan ese anuncio. Eses paquetes non son encamiñables por deseño, así que un router entre as dúas máquinas descártaos mesmo cando o tráfico unicast pasaría. Dous dispositivos no mesmo conmutador vense; os mesmos dous dispositivos en VLAN distintas, ou nunha rede de convidados con illamento de clientes, non. As consolas e os teléfonos adoitan seguir o mesmo patrón co seu propio protocolo de descubrimento, e por iso a plataforma importa tanto como o xogo.

De aquí veñen a maioría dos informes de “mesmo Wi-Fi, sen servidores”. Un SSID de convidados con illamento activado, un sistema mesh que pon a consola nun segmento separado ou un perfil de devasas que trata a subrede local como pública romperán o descubrimento mentres o acceso normal a internet segue funcionando. Comproba o axuste de illamento de clientes e a máscara de subrede antes de supor que o xogo ten a culpa.

Un servizo de salas non é unha ruta de rede

Cando o xogo usa unha sala aloxada, a lista de partidas vén dos servidores do operador, non da túa subrede. Unha VPN cambia o camiño que toman os teus paquetes cara a eses servidores, pero non cambia que salas che mostra o servizo, en que rexión se aloxa a partida nin se a túa conta ten dereito a unirse. Son respostas que dá o backend, e ningunha cantidade de encamiñamento as cambia.

Nese modelo un túnel é como moito unha variable de latencia e como mínimo un problema de xeodetección, porque o servizo ve o enderezo de saída en lugar do teu enderezo da rúa. A mesma lóxica aplícase ás invitacións de amigos e aos sistemas de grupo. Son funcións de nivel de conta que media a plataforma, e por iso dous xogadores na mesma LAN poden non verse nunha sala mentres ambos poden unirse á partida dun descoñecido.

Que pode reconstruír un túnel e que non

Un túnel é útil cando os xogadores están en lugares distintos e o xogo admite a unión directa por enderezo. Un túnel encamiñado transporta tráfico unicast entre os dous sitios; un túnel ponte, ou unha capa superposta que presenta un segmento Ethernet virtual, tamén pode transportar o descubrimento por broadcast do que depende o xogo directo por LAN. Esa é a distinción que hai que entender: o encamiñamento move paquetes entre subredes, a ponte fai que dous sitios parezan unha soa subrede.

O que un túnel non pode facer é engadir un modo multixogador que a aplicación non implementa. Se a edición eliminou a unión directa, un segmento LAN virtual non a restaurará. Se a sala esixe unha conta, un túnel non satisfará a comprobación. E se as dúas máquinas están detrás do mesmo NAT con illamento entre elas, unha capa superposta pode sortear o illamento, pero tamén é un rodeo da política, e iso é unha conversa con quen xestiona a rede.

Proba o camiño que o xogo usa de verdade

Comeza cun anfitrión e un cliente na mesma subrede, co illamento desactivado e sen túnel. Se iso funciona, o xogo e a edición admiten o que intentas facer, e calquera fallo posterior é un problema de camiño. Se falla aí, o túnel nunca foi a resposta.

Despois anota que di o manual sobre o método de unión, o porto ou o mecanismo de descubrimento e calquera requisito de conta. Move unha variable cada vez: primeiro a subrede, despois o segmento, despois o túnel. Garda o enderezo do anfitrión e a ruta exacta do menú para que a próxima sesión poida reproducir a proba en lugar de repetir a discusión.

Aclara a versión, quen fai de anfitrión, como se une a xente e que conta ou subscrición necesita a sesión, e anótao antes da data. Acaba con máis discusións que calquera túnel, e deixa un rexistro do que se probou.