Prievadų tikrintuvas sako atidaryta? Kodėl Minecraft žaidėjai vis tiek negali prisijungti

Kažkas paleidžia prievado patikrą, pamato žodį atidaryta ir mano, kad serveris išspręstas. Ką šis rezultatas iš tikrųjų reiškia, yra siaura: iš tikrintuvo vietos, tuo momentu, TCP ryšys į tą adresą ir prievadą buvo priimtas. Tai nieko nesako apie Minecraft protokolo rankos paspaudimą, paskyros autentifikavimą ar tai, ar serveris įleido žaidėją į pasaulį.

Tai keturi skirtingi sluoksniai, ir bet kurio iš jų gedimas žaidėjui duoda tą patį sakinį: neveikė.

Zondas tikrina tik tai, ką gali matyti

TCP ryšys užbaigiamas, kai abi pusės baigia trijų krypčių rankos paspaudimą, kuris yra žemiau visko, ką žaidimas žino. Zondas praneša, kad klausytojas egzistavo ir atsakė iš savo tinklo vietos. Jis negali pasakyti, kad klausytojas yra žaidimas, nes bet kuris procesas gali užimti prievadą ir priimti ryšius.

Vieta svarbi tiek pat, kiek rezultatas. Tikrintuvas viešajame internete tikrina vieną kelią iš vieno tinklo. Tikrintuvas, kurį operatorius paleidžia iš to paties tinklo vidaus, tikrina visiškai kitą kelią, ir teigiamas rezultatas ten beveik nieko nesako apie tai, ką patiria nuotolinis žaidėjas. Du skirtingi tikrintuvai pas du skirtingus tiekėjus gali net nesutarti dėl priežasčių, kurios neturi nieko bendra su jūsų serveriu.

Laikas taip pat svarbus. Zondo rezultatas apibūdina momentą, kai jis buvo paleistas, o namų ryšys su dinamišku adresu ar pakeista peradresavimo taisykle gali perkelti tikrąjį atsakymą kelias minutes vėliau. Užrašykite viešą adresą, prievadą, adresų šeimą ir laiką kartu su nuosprendžiu, kitaip stebėjimas nepakartojamas. Pakartokite patikrą iš tikrai kito tinklo, o ne iš telefono tame pačiame ryšyje.

Keturi sluoksniai tarp lizdo ir žaidėjo

Įsivaizduokite seką, kurią jungiantis klientas iš tikrųjų atlieka. Pirmiausia jis išsprendžia adresą, tada atidaro TCP ryšį į paskelbtą prievadą, tada kalba paties žaidimo protokolu, kad derėtųsi ir autentifikuotųsi, ir galiausiai serveris nusprendžia, ar ta tapatybė įleidžiama į pasaulį. Kiekvienas sluoksnis turi savo gedimo parašą, ir tik pirmasis matomas prievado tikrintuvui.

Numatytasis Java Edition prievadas yra 25565, bet operatorius gali paskelbti kitą išorinį prievadą ir peradresuoti jį į vidų, todėl skaičius, kurį įveda žaidėjas, nebūtinai yra skaičius, kurį mato serveris. Tikrintuvas, nukreiptas į neteisingą išorinį prievadą, praneša uždaryta, nors serveris visiškai sveikas, ir tai yra dažniausias klaidingas aliarmas visoje šioje srityje.

Vardai prideda dar vieną žingsnį virš prievado. Jei žaidėjas įveda serverio vardą, sprendimas turi grąžinti paskelbtą adresą, o įrenginyje tinklo viduje jis gali grąžinti privatų. Tai ne ugniasienės gedimas, ir joks prievadų peradresavimo kiekis to nepakeis.

Kodėl žaidėjas viduje eina kitu keliu

Žaidėjas tame pačiame LAN arba VPN, kuris pasiekia tą LAN, bando pasiekti viešą adresą iš vidaus. Užklausa eina į maršrutizatoriaus išorinį adresą, ir maršrutizatorius turi ją išversti atgal į vidų, o tai paprastai vadinama hairpinning arba NAT atspindžiu. Kad tai veiktų, ir vertimas pirmyn, ir grįžimo kelias turi sutapti, o daugelis namų maršrutizatorių to visai neįgyvendina.

Štai kodėl svečias iš išorės prisijungia, o šalia serverio sėdintis žmogus negali. Išorinis kelias tikrai tvarkingas; nepavyksta vidinė apylanka, ir ji nepavyksta taip, kad žaidėjo ekrane tai atrodo kaip serverio problema. Pats serverio žurnalas nusprendžia, kas įvyko, nes ryšys, kuris niekada nebuvo išverstas, niekada jo nepasiekia.

Yra du sąžiningi pataisymai ir vienas blogas įprotis. Geri variantai yra leisti vidiniams žaidėjams naudoti privatų adresą arba split-DNS vardą, kuris viduje išsprendžiamas į privatų adresą, arba įjungti atspindį maršrutizatoriuje, jei funkcija egzistuoja ir veikia tinkamai. Blogas įprotis yra atidaryti daugiau prievadų arba išjungti pagrindinio kompiuterio ugniasienę, kas negali paveikti vertimo, kurio maršrutizatorius niekada neatliko.

Netgate NAT atspindžio dokumentacija išsamiau aprašo išorės ir vidaus skirtumą bei split-DNS alternatyvą. Skaitykite ją kaip mechanizmo aprašymą, o ne kaip pažadą, kad koks nors konkretus VPN tiekėjas ar maršrutizatorius palaiko kiekvieną loopback variantą.

Rinkite įrodymus iš kiekvieno požiūrio taško

Kiekvienam testui užrašykite, kas jį paleido, iš kur, kokiu laiku, prieš kokį adresą ir prievadą, ir ką serveris užregistravo. Žaidimo atmetimas su aiškia priežastimi serverio konsolėje yra kitokia išvada nei ryšys, kuris niekada neatėjo, ir abu veda priešingomis kryptimis.

Jei leidžiami nuotoliniai žaidėjai prisijungia, o vienas vietinis žaidėjas negali, vietinis kelias yra likęs klausimas ir jis nusipelno atskiro tyrimo: kokį adresą naudojo klientas, ką maršrutizatorius padarė su vertimu ir ar serveris apskritai užregistravo kokį nors prisijungimo bandymą. Perduokite šiuos tris faktus tam, kam priklauso tinklas, o ne atidarykite prievadus atsitiktinai.