Poortkontrole sê oop? Waarom Minecraft-spelers steeds nie kan aansluit nie

Iemand laat ’n poortkontrole loop, sien die woord oop, en beskou die bediener as opgelos. Wat daardie uitslag werklik beteken, is eng: vanaf die kontrole se ligging, op daardie oomblik, is ’n TCP-verbinding na daardie adres en poort aanvaar. Dit sê niks oor die Minecraft-protokolhanddruk, rekeningverifikasie, of of die bediener die speler tot ’n wêreld toegelaat het nie.

Dit is vier verskillende lae, en ’n fout by enige een van hulle lewer dieselfde sin by die speler: dit het nie gewerk nie.

’n Peiling toets net wat dit kan sien

’n TCP-verbinding voltooi wanneer beide kante die drie-rigting-handdruk voltooi, wat onder alles lê wat die speletjie weet. Die peiling rapporteer dat ’n luisteraar bestaan het en vanaf sy netwerklokasie geantwoord het. Dit kan jou nie vertel dat die luisteraar die speletjie is nie, want enige proses kan ’n poort bind en verbindings aanvaar.

Die ligging maak net soveel saak soos die uitslag. ’n Kontrole op die openbare internet toets een pad vanaf een netwerk. ’n Kontrole wat die operateur van binne dieselfde netwerk laat loop, toets ’n heeltemal ander pad, en ’n positiewe uitslag daar sê byna niks oor wat ’n afgeleë speler ervaar nie. Twee verskillende kontroles by twee verskillende verskaffers kan selfs verskil om redes wat niks met jou bediener te doen het nie.

Tyd maak ook saak. ’n Peilingsuitslag beskryf die oomblik toe dit geloop het, en ’n tuisverbinding met ’n dinamiese adres of ’n veranderde deurverwysingsreël kan die werklike antwoord ’n paar minute later verskuif. Teken die openbare adres, die poort, die adresfamilie en die tyd saam met die uitslag aan, anders is die waarneming nie herhaalbaar nie. Herhaal die kontrole vanaf ’n werklik ander netwerk eerder as vanaf ’n selfoon op dieselfde verbinding.

Vier lae tussen ’n sok en ’n speler

Stel jou die volgorde voor wat ’n kliënt wat aansluit werklik uitvoer. Eers los dit die adres op, dan maak dit ’n TCP-verbinding na die gepubliseerde poort oop, dan praat dit die speletjie se eie protokol om te onderhandel en te verifieer, en uiteindelik besluit die bediener of daardie identiteit tot die wêreld toegelaat word. Elke laag het sy eie foutpatroon, en net die eerste een is vir ’n poortkontrole sigbaar.

Die verstekpoort vir Java Edition is 25565, maar die operateur kan ’n ander eksterne poort publiseer en dit na binne deurverwys, so die nommer wat ’n speler intik is nie noodwendig die nommer wat die bediener sien nie. ’n Kontrole wat op die verkeerde eksterne poort gemik is, rapporteer gesluit terwyl die bediener heeltemal gesond is, en dit is die algemeenste vals alarm in hierdie hele gebied.

Name voeg nog ’n stap bo die poort by. As ’n speler ’n gasheernaam intik, moet die oplossing die gepubliseerde adres teruggee, en op ’n masjien binne die netwerk kan dit eerder ’n private een teruggee. Dit is nie ’n firewall-fout nie en geen mate van poortdeurverwysing sal dit verander nie.

Waarom die speler binne ’n ander pad volg

’n Speler op dieselfde LAN, of op ’n VPN wat daardie LAN bereik, probeer om die openbare adres van binne te bereik. Die versoek gaan na die router se eksterne adres en die router moet dit terug na binne vertaal, wat die reëling is wat gewoonlik hairpinning of NAT-weerkaatsing genoem word. Beide die heenvertaling en die terugpad moet in lyn wees om dit te laat werk, en baie verbruikersrouters implementeer dit glad nie.

Dit is waarom die gas van buite aansluit en die persoon langs die bediener nie kan nie. Die eksterne pad is werklik in orde; die interne ompad is wat faal, en dit faal op ’n manier wat soos ’n bedienerprobleem van die speler se skerm lyk. Die bediener se eie logboek beslis wat gebeur het, want ’n verbinding wat nooit vertaal is nie, bereik dit nooit.

Daar is twee eerlike oplossings en een slegte gewoonte. Die goeie opsies is om interne spelers die private adres of ’n split-DNS-naam te laat gebruik wat intern na die private adres oplos, of om weerkaatsing op die router te aktiveer as die funksie bestaan en werk. Die slegte gewoonte is om meer poorte oop te maak of die gasheer-firewall af te skakel, wat niks kan doen aan ’n vertaling wat die router nooit uitgevoer het nie.

Die Netgate dokumentasie oor NAT-weerkaatsing beskryf die onderskeid tussen buite en binne en die split-DNS-alternatief in meer besonderhede. Lees dit as ’n beskrywing van die meganisme eerder as ’n belofte dat enige spesifieke VPN-verskaffer of router elke loopback-variant ondersteun.

Versamel bewyse uit elke oogpunt

Vir elke toets, skryf neer wie dit geloop het, van waar, op watter tyd, teen watter adres en poort, en wat die bediener gelog het. ’n Speletjieverwerping met ’n duidelike rede in die bedienerkonsole is ’n ander bevinding as ’n verbinding wat nooit aangekom het nie, en die twee lei in teenoorgestelde rigtings.

As toegelate afgeleë spelers aansluit en een plaaslike speler nie kan nie, is die plaaslike pad die oorblywende vraag en dit verdien sy eie ondersoek: watter adres het die kliënt gebruik, wat het die router met die vertaling gedoen, en het die bediener enige verbindingspoging aangeteken. Gee daardie drie feite aan wie ook al die netwerk besit, eerder as om poorte lukraak oop te maak.