Un grup de persones instal·la un joc, es connecta a la mateixa xarxa i veu una llista de servidors buida. El reflex és culpar la xarxa i buscar un túnel, però potser el joc no ha enviat mai cap paquet que un túnel pogués transportar. Abans que cap VPN entri en escena, esbrina quina de tres coses fa realment l’edició quan algú clica a multijugador.

Aquestes tres coses no són intercanviables. Una fa servir trànsit local directe, una altra pregunta a un servei qui més està jugant, i una tercera es nega a arrencar sense un compte. Un túnel pot ajudar amb la primera, és irrellevant per a la segona i no pot arreglar la tercera. Aquest ordre importa, perquè les tres poden produir la mateixa llista buida amb tres solucions diferents.

Què comprova el joc abans de llistar un amfitrió

La majoria de menús multijugador fan diverses coses en seqüència: confirmen el compte que ha iniciat sessió, comproven els drets de l’edició, consulten un backend per al lobby o els amics i només després miren la xarxa local. Qualsevol pas pot fallar en silenci, i la interfície normalment mostra la mateixa llista buida en tots dos casos. Per això “la LAN està trencada” és un diagnòstic que no pots fer només mirant la pantalla. Un error del backend, un dret caducat i una subxarxa aïllada són indistingibles des de la pantalla del lobby, i només un d’ells és un problema de xarxa.

Llegeix la documentació de la mateixa edició abans de canviar els paràmetres de xarxa. Els remasteritzats sovint abandonen la connexió directa per IP, substitueixen la descoberta a la LAN per un lobby allotjat o exigeixen un compte de plataforma que el llançament original no necessitava. La pàgina d’ajuda de l’actual Age of Empires II: Definitive Edition, per exemple, explica un lobby allotjat als servidors del joc on tries visibilitat, contrasenya i regió; això és un flux de treball de l’aplicació que cal verificar per a aquesta edició, no una prova sobre cap llançament anterior.

Fixa’t en el número de compilació i també en el nom de l’edició. Un pedaç pot moure un joc d’un model a un altre, i les instruccions escrites per a la compilació de llançament poden descriure un menú que ja no existeix.

Els paquets de descoberta moren al primer encaminador

El joc directe per LAN normalment depèn de broadcast o multicast: l’amfitrió s’anuncia a una adreça de tota la subxarxa i els clients escolten aquest anunci. Aquests paquets no són encaminables per disseny, així que un encaminador entre les dues màquines els descarta fins i tot quan el trànsit unicast passaria. Dos dispositius al mateix commutador es veuen; els mateixos dos dispositius en VLAN diferents, o en una xarxa de convidats amb aïllament de clients, no. Les consoles i els telèfons solen seguir el mateix patró amb el seu propi protocol de descoberta, i per això la plataforma importa tant com el joc.

D’aquí vénen la majoria d’informes de “mateix Wi-Fi, cap servidor”. Un SSID de convidats amb aïllament activat, un sistema mesh que posa la consola en un segment separat o un perfil de tallafocs que tracta la subxarxa local com a pública trencaran la descoberta mentre l’accés normal a internet continua funcionant. Comprova el paràmetre d’aïllament de clients i la màscara de subxarxa abans de suposar que el joc té la culpa.

Un servei de lobby no és un camí de xarxa

Quan el joc fa servir un lobby allotjat, la llista de partides ve dels servidors de l’operador, no de la teva subxarxa. Una VPN canvia el camí que fan els teus paquets fins a aquests servidors, però no canvia quins lobbies et mostra el servei, en quina regió s’allotja la partida ni si el teu compte té dret a unir-s’hi. Són respostes que dona el backend, i cap quantitat d’encaminament les canvia.

En aquest model, un túnel és com a màxim una variable de latència i com a mínim un problema de geodetecció, perquè el servei veu l’adreça de sortida i no la teva adreça del carrer. La mateixa lògica s’aplica a les invitacions d’amics i als sistemes de grup. Són funcions de nivell de compte que la plataforma media, i per això dos jugadors a la mateixa LAN poden no veure’s en un lobby mentre tots dos poden unir-se a la partida d’un desconegut.

Què pot reconstruir un túnel i què no

Un túnel és útil quan els jugadors són en llocs diferents i el joc admet la connexió directa per adreça. Un túnel encaminat transporta trànsit unicast entre els dos llocs; un túnel pont, o una capa superposada que presenta un segment Ethernet virtual, també pot transportar la descoberta per broadcast de la qual depèn el joc directe per LAN. Aquesta és la distinció que cal entendre: l’encaminament mou paquets entre subxarxes, el pont fa que dos llocs semblin una sola subxarxa.

El que un túnel no pot fer és afegir un mode multijugador que l’aplicació no implementa. Si l’edició ha eliminat la connexió directa, un segment LAN virtual no la restaurarà. Si el lobby exigeix un compte, un túnel no satisfarà la comprovació. I si les dues màquines són darrere del mateix NAT amb aïllament entre elles, una capa superposada pot esquivar l’aïllament, però també és un salt de política, i això és una conversa amb qui gestiona la xarxa.

Prova el camí que el joc fa servir realment

Comença amb un amfitrió i un client a la mateixa subxarxa, amb l’aïllament desactivat i sense túnel. Si això funciona, el joc i l’edició admeten el que vols fer, i qualsevol fallada posterior és un problema de camí. Si falla aquí, el túnel mai no era la resposta.

Després anota què diu el manual sobre el mètode de connexió, el port o el mecanisme de descoberta i qualsevol requisit de compte. Mou una variable alhora: primer la subxarxa, després el segment, després el túnel. Guarda l’adreça de l’amfitrió i el camí exacte del menú perquè la propera sessió pugui reproduir la prova en lloc de repetir la discussió.

Aclareix la versió, qui fa d’amfitrió, com s’hi connecta la gent i quin compte o subscripció necessita la sessió, i apunta-ho abans de la data. Acaba amb més discussions que qualsevol túnel, i deixa un registre del que s’ha provat.

Articles relacionats