Hvorfor dit LAN-spil forsvinder, før du tilføjer en VPN

En gruppe mennesker installerer et spil, forbinder til det samme netværk og ser en tom serverliste. Refleksen er at bebrejde netværket og lede efter en tunnel, men spillet har måske aldrig sendt en pakke, som en tunnel kunne bære. Før nogen VPN kommer ind i billedet, skal du finde ud af, hvilken af tre ting udgaven faktisk gør, når nogen klikker på multiplayer.

De tre er ikke udskiftelige. Én bruger direkte lokal trafik, én spørger en tjeneste, hvem der ellers spiller, og én nægter at starte uden en konto. En tunnel kan hjælpe med den første, er irrelevant for den anden og kan ikke rette den tredje. Den rækkefølge betyder noget, fordi alle tre kan give den samme tomme liste med tre forskellige løsninger.

Hvad spillet tjekker, før det viser en vært

De fleste multiplayer-menuer gør flere ting i rækkefølge: bekræfter den konto, der er logget ind, tjekker rettigheder for udgaven, spørger en backend om lobbyer eller venner og ser først derefter på det lokale netværk. Ethvert trin kan fejle lydløst, og grænsefladen viser normalt den samme tomme liste i begge tilfælde. Derfor er “LAN er i stykker” en diagnose, du ikke kan stille ud fra skærmen alene. En backend-fejl, en udløbet rettighed og et isoleret subnet kan ikke skelnes fra lobby-skærmen, og kun én af dem er overhovedet et netværksproblem.

Læs udgavens egen dokumentation, før du ændrer netværksindstillinger. Remasters dropper rutinemæssigt direkte IP-tilslutning, erstatter LAN-opdagelse med en hostet lobby eller kræver en platformskonto, som den oprindelige udgivelse aldrig havde brug for. Support-siden for den nuværende Age of Empires II: Definitive Edition gennemgår for eksempel en lobby hostet på spillets servere, hvor du vælger synlighed, adgangskode og region; det er en applikationsarbejdsgang, der skal verificeres for den udgave, ikke bevis om nogen tidligere udgivelse.

Bemærk build-nummeret såvel som udgavens navn. En patch kan flytte et spil fra en model til en anden, og instruktioner skrevet til launch-buildet kan beskrive en menu, der ikke findes længere.

Opdagelsespakker dør ved den første router

Direkte LAN-spil afhænger normalt af broadcast eller multicast: værten annoncerer sig selv på en adresse for hele subnettet, og klienter lytter efter den annoncering. Disse pakker kan ikke routes efter design, så en router mellem de to maskiner kasserer dem, selv når unicast-trafik ville komme igennem. To enheder på samme switch ser hinanden; de samme to enheder på forskellige VLAN'er eller på et gæstenetværk med klientisolering gør ikke. Konsoller og telefoner følger normalt samme mønster med deres egen opdagelsesprotokol, og derfor betyder platformen lige så meget som spillet.

Det er her, de fleste rapporter om “samme Wi-Fi, ingen servere” kommer fra. Et gæste-SSID med isolering slået til, et mesh-system der placerer konsollen på et separat segment, eller en firewall-profil der behandler det lokale subnet som offentligt vil hver især bryde opdagelsen, mens almindelig internetadgang fortsat virker. Tjek indstillingen for klientisolering og subnet-masken, før du antager, at spillet er skyld i det.

En lobbytjeneste er ikke en netværksvej

Når spillet bruger en hostet lobby, kommer listen over kampe fra operatørens servere, ikke fra dit subnet. En VPN ændrer den vej, dine pakker tager til de servere, men den ændrer ikke, hvilke lobbyer tjenesten viser dig, hvilken region kampen hostes i, eller om din konto har ret til at deltage. Det er svar, backend giver, og ingen mængde routing ændrer dem.

I den model er en tunnel i bedste fald en latenstidsvariabel og i værste fald et geo-detekteringsproblem, fordi tjenesten ser exit-adressen i stedet for din gadeadresse. Den samme logik gælder for venneinvitationer og partysystemer. De er kontoniveau-funktioner, som platformen formidler, og derfor kan to spillere på samme LAN undgå at se hinanden i en lobby, mens begge kan deltage i en fremmeds kamp.

Hvad en tunnel kan genopbygge, og hvad den ikke kan

En tunnel er nyttig, når spillerne er på forskellige steder, og spillet understøtter direkte tilslutning via adresse. En routed tunnel bærer unicast-trafik mellem de to steder; en bridged tunnel eller et overlay, der præsenterer et virtuelt Ethernet-segment, kan også bære den broadcast-opdagelse, som direkte LAN-spil afhænger af. Det er den forskel, der skal forstås: routing flytter pakker mellem subnet, bridging får to steder til at ligne ét subnet.

Hvad en tunnel ikke kan, er at tilføje en multiplayer-tilstand, som applikationen ikke implementerer. Hvis udgaven har fjernet direkte tilslutning, gendanner et virtuelt LAN-segment det ikke. Hvis lobbyen kræver en konto, opfylder en tunnel ikke det tjek. Og hvis de to maskiner sidder bag samme NAT med isolering mellem sig, kan et overlay omgå isoleringen, men det er også en omgåelse af politik, og det er en samtale med den, der driver netværket.

Test den vej, spillet faktisk bruger

Start med én vært og én klient på samme subnet, isolering slået fra og ingen tunnel. Hvis det virker, understøtter spillet og udgaven det, du prøver på, og enhver senere fejl er et vejproblem. Hvis det fejler der, var tunnelen aldrig svaret.

Skriv derefter ned, hvad manualen siger om tilslutningsmetoden, porten eller opdagelsesmekanismen og eventuelle kontokrav. Flyt én variabel ad gangen: først subnet, så segment, så tunnel. Noter værtens adresse og den præcise menustig, så næste session kan gentage testen i stedet for at gentage diskussionen.

Afklar versionen, hvem der er vært, hvordan folk tilslutter sig, og hvilken konto eller hvilket abonnement sessionen kræver, og skriv det ned inden datoen. Det afslutter flere diskussioner, end nogen tunnel nogensinde vil, og det efterlader en registrering af, hvad der blev testet.