Kial via LAN-ludo malaperas antaŭ ol vi aldonas VPN

Grupo da homoj instalas ludon, konektiĝas al la sama reto kaj vidas malplenan servilan liston. La reflekso estas kulpigi la reton kaj serĉi tunelon, sed la ludo eble neniam sendis paketon, kiun tunelo povus porti. Antaŭ ol iu ajn VPN eniras la bildon, eltrovu, kiun el tri aferoj la eldono efektive faras, kiam iu alklakas multludanton.

La tri ne estas interŝanĝeblaj. Unu uzas rektan lokan trafikon, alia demandas servon, kiu ankoraŭ ludas, kaj tria rifuzas starti sen konto. Tunelo povas helpi ĉe la unua, estas senrilata al la dua kaj ne povas ripari la trian. Tiu ordo gravas, ĉar ĉiuj tri povas produkti la saman malplenan liston per tri malsamaj solvoj.

Kion la ludo kontrolas antaŭ ol listigi gastiganton

Plej multaj multludaj menuoj faras plurajn aferojn sinsekve: konfirmas la ensalutitan konton, kontrolas la rajtojn de la eldono, demandas dorsan servon pri ĉambregoj aŭ amikoj kaj nur poste rigardas la lokan reton. Ĉiu paŝo povas malsukcesi silente, kaj la interfaco kutime montras la saman malplenan liston en ambaŭ kazoj. Tial “la LAN estas rompita” estas diagnozo, kiun vi ne povas fari nur laŭ la ekrano. Eraro en la dora servo, eksvalidiĝinta rajto kaj izolita subreto ne distingiĝas de la ĉambrega ekrano, kaj nur unu el ili entute estas reta problemo.

Legi la dokumentaron de la eldono mem antaŭ ol ŝanĝi retajn agordojn. Revizioj kutime forlasas rektan IP-aliĝon, anstataŭigas LAN-malkovron per gastigita ĉambrego aŭ postulas platforman konton, kiun la originala eldono neniam bezonis. La subtena paĝo por la nuna Age of Empires II: Definitive Edition, ekzemple, priskribas ĉambregon gastigatan sur la serviloj de la ludo, kie vi elektas videblecon, pasvorton kaj regionon; tio estas aplikada laborfluo, kiun oni devas kontroli por tiu eldono, ne pruvo pri iu ajn pli frua eldono.

Notu la numero de la konstruo same kiel la nomon de la eldono. Flikaĵo povas movi ludon de unu modelo al alia, kaj instrukcioj skribitaj por la lanĉa konstruo povas priskribi menuon, kiu ne plu ekzistas.

Malkovraj paketoj mortas ĉe la unua enkursigilo

Rekta LAN-ludo kutime dependas de brodkasto aŭ multkasto: la gastiganto anoncas sin al adreso de la tuta subreto, kaj klientoj aŭskultas tiun anoncon. Tiuj paketoj ne estas enkursigeblaj laŭ dizajno, do enkursigilo inter la du maŝinoj forĵetas ilin eĉ kiam unukasta trafiko pasus. Du aparatoj sur la sama komutilo vidas unu la alian; la samaj du aparatoj sur malsamaj VLAN-oj aŭ en gastiga reto kun klienta izolado ne vidas unu la alian. Konzoloj kaj telefonoj kutime sekvas la saman ŝablonon kun sia propra malkovra protokolo, kaj tial la platformo gravas same kiel la ludo.

De ĉi tie venas plej multaj raportoj pri “sama Wi-Fi, neniuj serviloj”. Gastiga SSID kun ŝaltita izolado, maŝa sistemo, kiu metas la konzolon sur apartan segmenton, aŭ fajroŝirma profilo, kiu traktas la lokan subreton kiel publikan, ĉiu el ili rompos la malkovron dum ordinara interreta aliro daŭre funkcias. Kontrolu la agordon de klienta izolado kaj la subretan maskon antaŭ ol supozi, ke la ludo kulpas.

Ĉambroga servo ne estas reta vojo

Kiam la ludo uzas gastigitan ĉambregon, la listo de matĉoj venas de la serviloj de la funkciigisto, ne de via subreto. VPN ŝanĝas la vojon, kiun viaj paketoj prenas al tiuj serviloj, sed ĝi ne ŝanĝas, kiujn ĉambregojn la servo montras al vi, en kiu regiono la matĉo estas gastigita, aŭ ĉu via konto rajtas aliĝi. Tiuj estas respondoj de la dora servo, kaj neniu kvanto da enkursigado ŝanĝas ilin.

En tiu modelo tunelo estas plej bone variablo de latenteco kaj plej malbone problemo de geo-detekto, ĉar la servo vidas la eliran adreson anstataŭ vian stratadreson. La sama logiko validas por amikaj invitiloj kaj teamaj sistemoj. Ili estas funkcioj je konto-nivelo, kiujn peras la platformo, kaj tial du ludantoj sur la sama LAN povas maltrafi unu la alian en ĉambrego, dum ambaŭ povas aliĝi al matĉo de fremdulo.

Kion tunelo povas rekonstrui, kaj kion ne

Tunelo utilas, kiam la ludantoj estas en malsamaj lokoj kaj la ludo subtenas rektan aliĝon laŭ adreso. Enkursigita tunelo portas unukastan trafikon inter la du ejoj; pontigita tunelo, aŭ tavolo, kiu prezentas virtualan Ethernet-segmenton, povas ankaŭ porti la brodkastan malkovron, de kiu dependas rekta LAN-ludo. Jen la distingo komprenenda: enkursigado movas paketojn inter subretoj, pontigado igas du ejojn aspekti kiel unu subreto.

Kion tunelo ne povas fari, estas aldoni multludan reĝimon, kiun la aplikaĵo ne realigas. Se la eldono forigis rektan aliĝon, virtuala LAN-segmento ne restarigos ĝin. Se la ĉambrego postulas konton, tunelo ne plenumos tiun kontrolon. Kaj se la du maŝinoj sidas malantaŭ la sama NAT kun izolado inter ili, tavolo povas ĉirkaŭiri la izoladon, sed ĝi ankaŭ estas ĉirkaŭiro de politiko, do konversacio kun tiu, kiu administras la reton.

Testu la vojon, kiun la ludo efektive uzas

Komencu per unu gastiganto kaj unu kliento sur la sama subreto, kun izolado malŝaltita kaj sen tunelo. Se tio funkcias, la ludo kaj la eldono subtenas tion, kion vi provas fari, kaj ajna posta malsukceso estas voja problemo. Se ĝi malsukcesas tie, la tunelo neniam estis la respondo.

Poste notu, kion la manlibro diras pri la aliĝmetodo, la pordo aŭ la malkovra mekanismo kaj ajna konte postuloj. Movu unu variablon samtempe: unue la subreton, poste la segmenton, poste la tunelon. Kaptu la adreson de la gastiganto kaj la precizan menuvojon, por ke la sekva sesio povu ripeti la teston anstataŭ ripeti la disputon.

Klariĝu la version, kiu gastigas, kiel homoj aliĝas kaj kiun konton aŭ abonon la sesio bezonas, kaj skribu tion antaŭ la dato. Ĝi finas pli da disputoj, ol iu ajn tunelo iam finos, kaj ĝi lasas registron pri tio, kio estis testita.