Kontrola portu říká otevřeno? Proč se hráči Minecraftu stále nemohou připojit
Úspěšné TCP spojení dokazuje jen to, že jeden socket byl přijat z jednoho místa. Přihlášení, vpuštění do světa a cesta zevnitř ven jsou oddělené testy.
Někdo spustí kontrolu portu, uvidí slovo otevřeno a považuje server za vyřešený. Co tento výsledek skutečně znamená, je úzké: z místa kontroly, v daném okamžiku, bylo přijato TCP spojení na danou adresu a port. Nic neříká o handshake protokolu Minecraft, ověření účtu ani o tom, zda server hráče vpustil do světa.
To jsou čtyři různé vrstvy a selhání v kterékoli z nich vyvolá u hráče stejnou větu: nefungovalo to.
Sonda testuje jen to, co vidí
TCP spojení se dokončí, když obě strany dokončí třícestný handshake, který leží pod vším, co hra zná. Sonda hlásí, že existoval posluchač a odpověděl ze svého síťového místa. Nemůže vám říct, že posluchačem je hra, protože jakýkoli proces může obsadit port a přijímat spojení.
Místo je stejně důležité jako výsledek. Kontrola na veřejném internetu testuje jednu cestu z jedné sítě. Kontrola, kterou provozovatel spustí zevnitř stejné sítě, testuje zcela jinou cestu, a kladný výsledek tam neříká téměř nic o tom, co zažívá vzdálený hráč. Dvě různé kontroly u dvou různých poskytovatelů se dokonce mohou rozejít z důvodů, které s vaším serverem nemají nic společného.
Záleží i na čase. Výsledek sondy popisuje okamžik, kdy běžela, a domácí připojení s dynamickou adresou nebo změněným pravidlem přesměrování může skutečnou odpověď posunout o několik minut. Zapište veřejnou adresu, port, rodinu adres a čas spolu s verdiktem, jinak pozorování nelze reprodukovat. Kontrolu opakujte ze skutečně jiné sítě, ne z telefonu na stejném připojení.
Čtyři vrstvy mezi socketem a hráčem
Představte si sled, který připojující se klient skutečně provádí. Nejprve přeloží adresu, potom otevře TCP spojení na publikovaný port, potom mluví vlastním protokolem hry, aby vyjednal a ověřil, a nakonec server rozhodne, zda tato identita smí do světa. Každá vrstva má vlastní podpis selhání a kontrole portu je vidět jen ta první.
Výchozí port Java Edition je 25565, ale provozovatel může publikovat jiný vnější port a přesměrovat ho dovnitř, takže číslo, které hráč zadá, nemusí být číslo, které vidí server. Kontrola namířená na špatný vnější port hlásí zavřeno, i když je server naprosto zdravý, a to je v celé této oblasti nejčastější falešný poplach.
Jména přidávají nad port ještě jeden krok. Pokud hráč zadá název hostitele, překlad musí vrátit publikovanou adresu, a na stroji uvnitř sítě může místo ní vrátit privátní. To není selhání firewallu a žádné množství přesměrování portů to nezmění.
Proč hráč zevnitř jde jinou cestou
Hráč ve stejné LAN, nebo ve VPN, která do té LAN dosáhne, se snaží dosáhnout veřejné adresy zevnitř. Požadavek jde na vnější adresu routeru a router ho musí přeložit zpět dovnitř, což je uspořádání obvykle nazývané hairpinning nebo NAT reflexe. Aby to fungovalo, musí se sejít jak překlad dopředu, tak zpětná cesta, a mnoho domácích routerů to vůbec neimplementuje.
Proto se host zvenčí připojí a člověk sedící vedle serveru ne. Vnější cesta je skutečně v pořádku; selhává vnitřní objížďka a selhává tak, že to na hráčově obrazovce vypadá jako problém serveru. Vlastní log serveru rozhodne, co se stalo, protože spojení, které nebylo nikdy přeloženo, k němu nikdy nedorazí.
Existují dvě poctivé opravy a jeden špatný zvyk. Dobré možnosti jsou nechat vnitřní hráče použít privátní adresu nebo jméno split-DNS, které se uvnitř přeloží na privátní adresu, nebo zapnout reflexi na routeru, pokud funkce existuje a chová se správně. Špatný zvyk je otevírat další porty nebo vypínat firewall hostitele, což nemůže ovlivnit překlad, který router nikdy neprovedl.
Dokumentace Netgate k NAT reflexi podrobněji popisuje rozdíl mezi vnějškem a vnitřkem a alternativu split-DNS. Čtěte ji jako popis mechanismu, ne jako slib, že konkrétní poskytovatel VPN nebo router podporuje každou variantu loopbacku.
Sbírejte důkazy z každého pohledu
Ke každému testu zapište, kdo ho spustil, odkud, v kolik hodin, proti které adrese a portu a co server zalogoval. Odmítnutí hry s jasným důvodem v konzoli serveru je jiné zjištění než spojení, které nikdy nedorazilo, a obě vedou opačným směrem.
Pokud se povolení vzdálení hráči připojují a jeden místní hráč nemůže, zbývající otázkou je místní cesta a zaslouží si vlastní vyšetřování: kterou adresu klient použil, co router s překladem udělal a zda server zaznamenal vůbec nějaký pokus o spojení. Předejte tyto tři skutečnosti tomu, kdo vlastní síť, místo abyste náhodně otvírali porty.