A portellenőrző azt mondja nyitott? Miért nem tudnak mégis csatlakozni a Minecraft játékosok

Valaki lefuttat egy portellenőrzést, meglátja a nyitott szót, és a szervert megoldottnak tekinti. Amit ez az eredmény valójában jelent, az szűk: az ellenőrző helyéről, abban a pillanatban, egy TCP-kapcsolatot fogadtak el arra a címre és portra. Semmit nem mond a Minecraft protokoll kézfogásáról, a fiók hitelesítéséről, vagy arról, hogy a szerver beengedte-e a játékost egy világba.

Ez négy különböző réteg, és bármelyikük hibája ugyanazt a mondatot váltja ki a játékosból: nem működött.

A vizsgálat csak azt teszteli, amit lát

A TCP-kapcsolat akkor jön létre, amikor mindkét fél befejezi a háromutas kézfogást, amely minden alatt van, amit a játék tud. A vizsgálat jelenti, hogy létezett egy figyelő, és válaszolt a saját hálózati helyéről. Nem tudja megmondani, hogy a figyelő maga a játék, mert bármely folyamat lefoglalhat egy portot és fogadhat kapcsolatokat.

A hely ugyanolyan fontos, mint az eredmény. A nyilvános interneten lévő ellenőrző egy hálózatból egy utat tesztel. Az az ellenőrző, amelyet az üzemeltető ugyanazon hálózat belsejéből futtat, teljesen más utat tesztel, és az ottani pozitív eredmény szinte semmit nem mond arról, amit egy távoli játékos tapasztal. Két különböző ellenőrző két különböző szolgáltatónál még abban is eltérhet, aminek semmi köze a szerveredhez.

Az időzítés is számít. A vizsgálat eredménye azt a pillanatot írja le, amikor futott, és egy dinamikus című vagy megváltozott továbbítási szabályú otthoni kapcsolat néhány perccel később elmozdíthatja a valódi választ. Jegyezd fel a nyilvános címet, a portot, a címcsaládot és az időpontot az ítélettel együtt, különben a megfigyelés nem reprodukálható. Ismételd meg az ellenőrzést egy valóban más hálózatból, ne egy ugyanazon kapcsolaton lévő telefonról.

Négy réteg egy socket és egy játékos között

Képzeld el a sorrendet, amelyet egy csatlakozó kliens valóban végrehajt. Először feloldja a címet, aztán TCP-kapcsolatot nyit a közzétett portra, aztán a játék saját protokollján tárgyal és hitelesít, végül a szerver eldönti, hogy az az identitás beléphet-e a világba. Minden rétegnek megvan a maga hiba-aláírása, és csak az első látható egy portellenőrző számára.

A Java Edition alapértelmezett portja a 25565, de az üzemeltető közzétehet egy másik külső portot, és befelé továbbíthatja, így a játékos által beírt szám nem feltétlenül az a szám, amelyet a szerver lát. A rossz külső portra irányított ellenőrző zártként jelent, miközben a szerver teljesen egészséges, és ez a leggyakoribb téves riasztás ezen a területen.

A nevek még egy lépést adnak a port fölé. Ha a játékos hosztnevet ír be, a feloldásnak a közzétett címet kell visszaadnia, és a hálózaton belüli gépen ehelyett egy privát címet adhat vissza. Ez nem tűzfalkudarc, és semmilyen porttovábbítás nem változtat rajta.

Miért más utat választ a benti játékos

Az ugyanazon a LAN-on vagy az azt elérő VPN-en lévő játékos belülről próbálja elérni a nyilvános címet. A kérés a router külső címére megy, és a routernek vissza kell fordítania befelé, ezt a megoldást szokás hairpinningnek vagy NAT-tükrözésnek nevezni. Ahhoz, hogy ez működjön, az oda- és a visszaútnak is egyeznie kell, és sok otthoni router egyáltalán nem valósítja meg.

Ezért csatlakozik a kívülről jövő vendég, és ezért nem tud az, aki a szerver mellett ül. A külső út valóban rendben van; a belső kerülő az, ami elakad, és úgy akad el, hogy a játékos képernyőjén szerverhibának látszik. A szerver saját naplója dönti el, melyik történt, mert egy soha le nem fordított kapcsolat soha nem ér el hozzá.

Két őszinte javítás és egy rossz szokás létezik. A jó lehetőségek, hogy a belső játékosok a privát címet vagy egy split-DNS nevet használják, amely belül a privát címre oldódik fel, vagy hogy engedélyezd a tükrözést a routeren, ha a funkció létezik és megfelelően viselkedik. A rossz szokás több port megnyitása vagy a hoszt tűzfalának kikapcsolása, ami nem hathat arra a fordításra, amelyet a router soha nem végzett el.

A Netgate NAT-tükrözésről szóló dokumentációja részletesebben leírja a külső és belső közötti különbséget és a split-DNS alternatívát. A mechanizmus leírásaként olvasd, nem ígéretként arra, hogy egy adott VPN-szolgáltató vagy router minden loopback-változatot támogat.

Gyűjts bizonyítékot minden nézőpontból

Minden teszthez írd fel, ki futtatta, honnan, mikor, melyik cím és port ellen, és mit naplózott a szerver. A játék világos okkal történő elutasítása a szerverkonzolon más lelet, mint egy soha meg nem érkezett kapcsolat, és a kettő ellentétes irányba vezet.

Ha az engedélyezett távoli játékosok csatlakoznak, és egy helyi játékos nem tud, akkor a helyi út a fennmaradó kérdés, és saját vizsgálatot érdemel: melyik címet használta a kliens, mit tett a router a fordítással, és rögzített-e a szerver egyáltalán bármilyen kapcsolódási kísérletet. Add át ezt a három tényt a hálózat tulajdonosának, ahelyett hogy találomra újra megnyitnád a portokat.