Ինչու է ձեր LAN խաղը կորչում VPN ավելացնելուց առաջ

Մի խումբ մարդիկ տեղադրում են խաղ, միանում նույն ցանցին և տեսնում սերվերների դատարկ ցանկ։ Ռեֆլեքսը ցանցին մեղադրելն ու թունել փնտրելն է, բայց գուցե խաղը երբեք չի ուղարկել փաթեթ, որը թունելը կարող էր տանել։ Նախքան որևէ VPN կհայտնվի պատկերում, պարզեք, թե հրատարակությունը երեք բաներից որն է իրականում անում, երբ ինչ-որ մեկը սեղմում է բազմախաղացող ռեժիմը։

Այդ երեքը փոխարինելի չեն։ Մեկը օգտագործում է ուղիղ տեղային երթևեկություն, մեկը հարցնում է ծառայությանը, թե ով էլ է խաղում, իսկ մեկը հրաժարվում է սկսել առանց հաշվի։ Թունելը կարող է օգնել առաջինին, անտեղի է երկրորդի համար և չի կարող շտկել երրորդը։ Այդ հերթականությունը կարևոր է, քանի որ բոլոր երեքը կարող են տալ նույն դատարկ ցանկը՝ երեք տարբեր լուծումներով։

Ինչ է ստուգում խաղը նախքան հոսթը ցանկում հայտնվելը

Բազմախաղացող ռեժիմի մենյուների մեծ մասը հաջորդաբար մի քանի բան է անում՝ հաստատում է մուտք գործած հաշիվը, ստուգում է հրատարակության իրավունքները, հարցում է backend-ից լոբբիների կամ ընկերների մասին և միայն դրանից հետո նայում տեղային ցանցին։ Ցանկացած քայլ կարող է լուռ ձախողվել, և ինտերֆեյսը սովորաբար երկու դեպքում էլ ցույց է տալիս նույն դատարկ ցանկը։ Այդ պատճառով «LAN-ը փչացած է» այն ախտորոշումն է, որը հնարավոր չէ անել միայն էկրանից։ Backend-ի սխալը, ժամկետանց իրավունքը և մեկուսացված ենթացանցը լոբբիի էկրանից չեն տարբերվում, և դրանցից միայն մեկն է ընդհանրապես ցանցային խնդիր։

Նախքան ցանցային կարգավորումները փոխելը կարդացեք հենց հրատարակության փաստաթղթերը։ Վերահրատարակությունները սովորաբար հանում են IP-ով ուղիղ միացումը, LAN հայտնաբերումը փոխարինում են հոսթավորված լոբբիով կամ պահանջում են հարթակի հաշիվ, որը բնօրինակ թողարկմանը երբեք պետք չէր։ Ընթացիկ Age of Empires II: Definitive Edition-ի աջակցության էջը, օրինակ, նկարագրում է խաղի սերվերներում հոսթավորված լոբբի, որտեղ ընտրում եք տեսանելիությունը, գաղտնաբառը և տարածաշրջանը՝ դա այդ հրատարակության համար ստուգման ենթակա հավելվածի ընթացք է, ոչ թե որևէ ավելի վաղ թողարկման ապացույց։

Նշեք նաև build-ի համարը, ոչ միայն հրատարակության անվանումը։ Կարկատան կարող է խաղը մի մոդելից տեղափոխել մյուսը, և մեկնարկային build-ի համար գրված հրահանգները կարող են նկարագրել մենյու, որն այլևս գոյություն չունի։

Հայտնաբերման փաթեթները մահանում են առաջին երթուղիչում

Ուղիղ LAN խաղը սովորաբար հենվում է broadcast-ի կամ multicast-ի վրա՝ հոսթը հայտարարում է իրեն ամբողջ ենթացանցի հասցեով, և հաճախորդները լսում են այդ հայտարարությունը։ Այդ փաթեթները ըստ նախագծման երթուղելի չեն, ուստի երկու մեքենաների միջև եղած երթուղիչը դեն է նետում դրանք նույնիսկ այն դեպքում, երբ unicast երթևեկությունը կանցներ։ Նույն սվիչի վրա երկու սարք տեսնում են միմյանց, իսկ նույն երկու սարքերը տարբեր VLAN-ներում կամ հաճախորդների մեկուսացումով հյուրային ցանցում իրար չեն տեսնում։ Կոնսոլներն ու հեռախոսները սովորաբար նույն օրինաչափությունն են կրկնում իրենց հայտնաբերման արձանագրությամբ, այդ պատճառով հարթակը նույնքան կարևոր է, որքան խաղը։

Այստեղից է գալիս «նույն Wi-Fi-ը, սերվերներ չկան» հաղորդումների մեծ մասը։ Մեկուսացումը միացված հյուրային SSID-ը, կոնսոլը առանձին սեգմենտի վրա դնող mesh համակարգը կամ տեղային ենթացանցը որպես հանրային դիտող firewall-ի պրոֆիլը՝ յուրաքանչյուրը կկոտրի հայտնաբերումը, մինչ սովորական ինտերնետ հասանելիությունը կշարունակի աշխատել։ Ստուգեք հաճախորդների մեկուսացման կարգավորումը և ենթացանցի դիմակը նախքան խաղին մեղադրելը։

Լոբբիի ծառայությունը ցանցային ուղի չէ

Երբ խաղը օգտագործում է հոսթավորված լոբբի, խաղերի ցանկը գալիս է օպերատորի սերվերներից, ոչ թե ձեր ենթացանցից։ VPN-ն փոխում է այն ուղին, որով ձեր փաթեթները հասնում են այդ սերվերներին, բայց չի փոխում, թե ծառայությունը ձեզ որ լոբբիներն է ցույց տալիս, որ տարածաշրջանում է հոսթավորված խաղը կամ արդյոք ձեր հաշիվն իրավունք ունի միանալու։ Այդ պատասխանները տալիս է backend-ը, և ոչ մի երթուղավորում դրանք չի փոխում։

Այդ մոդելում թունելը լավագույն դեպքում ուշացման փոփոխական է, իսկ վատագույն դեպքում՝ աշխարհագրական հայտնաբերման խնդիր, քանի որ ծառայությունը տեսնում է ելքի հասցեն, ոչ թե ձեր փողոցի հասցեն։ Նույն տրամաբանությունը վերաբերում է ընկերների հրավերներին և խմբային համակարգերին։ Դրանք հաշվի մակարդակի գործառույթներ են, որոնք միջնորդում է հարթակը, այդ պատճառով նույն LAN-ի վրա երկու խաղացող կարող են իրար չտեսնել լոբբիում, մինչդեռ երկուսն էլ կարող են միանալ անծանոթի խաղին։

Ինչ կարող է վերականգնել թունելը և ինչ ոչ

Թունելը օգտակար է, երբ խաղացողները տարբեր վայրերում են, և խաղը աջակցում է հասցեով ուղիղ միացում։ Երթուղավորված թունելը unicast երթևեկություն է տեղափոխում երկու վայրերի միջև, կամրջված թունելը կամ վիրտուալ Ethernet սեգմենտ ներկայացնող overlay-ը կարող է տանել նաև broadcast հայտնաբերումը, որից կախված է ուղիղ LAN խաղը։ Սա այն տարբերությունն է, որ պետք է հասկանալ՝ երթուղավորումը փաթեթներ է տեղափոխում ենթացանցերի միջև, կամրջումը երկու վայրերին դարձնում է մեկ ենթացանցի նման։

Թունելը չի կարող ավելացնել բազմախաղացող ռեժիմ, որը հավելվածը չի ներդրել։ Եթե հրատարակությունը հանել է ուղիղ միացումը, վիրտուալ LAN սեգմենտը այն հետ չի բերի։ Եթե լոբբին հաշիվ է պահանջում, թունելը չի բավարարի ստուգումը։ Իսկ եթե երկու մեքենաները նույն NAT-ի հետևում են՝ իրար միջև մեկուսացումով, overlay-ը կարող է շրջանցել մեկուսացումը, բայց դա նաև քաղաքականության շրջանցում է, ինչի մասին պետք է խոսել ցանցը ղեկավարողի հետ։

Փորձարկեք այն ուղին, որն իրականում օգտագործում է խաղը

Սկսեք մեկ հոսթով և մեկ հաճախորդով նույն ենթացանցում, անջատված մեկուսացումով և առանց թունելի։ Եթե դա աշխատում է, խաղն ու հրատարակությունը աջակցում են ձեր փորձին, և ցանկացած հետագա ձախողում ուղու խնդիր է։ Եթե այնտեղ է ձախողվում, թունելը երբեք պատասխանը չի եղել։

Այնուհետև գրեք, թե ձեռնարկն ինչ է ասում միացման եղանակի, պորտի կամ հայտնաբերման մեխանիզմի և հաշվի ցանկացած պահանջի մասին։ Փոխեք մեկ փոփոխական միաժամանակ՝ սկզբում ենթացանցը, հետո սեգմենտը, հետո թունելը։ Գրանցեք հոսթի հասցեն և մենյուի ճշգրիտ ուղին, որպեսզի հաջորդ նստաշրջանը կրկնի փորձարկումը, այլ ոչ թե վեճը։

Հստակեցրեք տարբերակը, թե ով է հոսթում, ինչպես են մարդիկ միանում և որ հաշիվը կամ բաժանորդագրությունն է պետք նստաշրջանին, և գրեք դա մինչև օրը։ Դա ավելի շատ վեճեր է վերջացնում, քան ցանկացած թունել, և թողնում է գրառում այն մասին, ինչ փորձարկվել է։