La havena kontrolilo diras malfermita? Kial Minecraft-ludantoj ankoraŭ ne povas aliĝi

Iu rulas havenan kontrolon, vidas la vorton malfermita kaj konsideras la servilon solvita. Kion tiu rezulto vere signifas estas mallarĝe: de la pozicio de la kontrolilo, en tiu momento, TCP-ligo al tiu adreso kaj haveno estis akceptita. Ĝi diras nenion pri la manaŭzo de la Minecraft-protokolo, la konto-konfirmo aŭ ĉu la servilo lasis la ludanton en mondon.

Tiuj estas kvar malsamaj tavoloj, kaj fiasko en iu ajn el ili produktas la saman frazon de la ludanto: ĝi ne funkciis.

Sondilo testas nur tion, kion ĝi povas vidi

TCP-ligo kompletiĝas kiam ambaŭ flankoj finas la triopan manaŭzon, kiu kuŝas sub ĉio, kion la ludo scias. La sondilo raportas, ke aŭskultanto ekzistis kaj respondis el sia reta pozicio. Ĝi ne povas diri al vi, ke la aŭskultanto estas la ludo, ĉar iu ajn procezo povas okupi havenon kaj akcepti ligojn.

La pozicio gravas same kiel la rezulto. Kontrolilo en la publika interreto testas unu vojon el unu reto. Kontrolilo, kiun la administranto rulas de interne de la sama reto, testas tute alian vojon, kaj pozitiva rezulto tie diras preskaŭ nenion pri tio, kion spertas fora ludanto. Du malsamaj kontroliloj ĉe du malsamaj provizantoj eĉ povas malkonsenti pro kialoj, kiuj havas nenion komunan kun via servilo.

Ankaŭ la tempo gravas. Sondila rezulto priskribas la momenton, kiam ĝi ruliĝis, kaj hejma ligo kun dinamika adreso aŭ ŝanĝita plusenda regulo povas movi la veran respondon kelkajn minutojn poste. Notu la publikan adreson, la havenon, la adresan familion kaj la tempon kune kun la verdikto, alie la observo ne estas ripetebla. Ripetu la kontrolon el vere alia reto anstataŭ el telefono sur la sama ligo.

Kvar tavoloj inter soketo kaj ludanto

Imagu la sinsekvon, kiun aliĝanta kliento efektive plenumas. Unue ĝi solvas la adreson, poste ĝi malfermas TCP-ligon al la publikigita haveno, poste ĝi parolas la propran protokolon de la ludo por intertrakti kaj konfirmi, kaj fine la servilo decidas, ĉu tiu identeco rajtas eniri la mondon. Ĉiu tavolo havas sian propran fiaskan subskribon, kaj nur la unua estas videbla al havena kontrolilo.

La defaŭlta haveno de Java Edition estas 25565, sed la administranto povas publikigi alian eksteran havenon kaj plusendi ĝin internen, do la nombro, kiun ludanto tajpas, ne nepre estas la nombro, kiun la servilo vidas. Kontrolilo celanta la malĝustan eksteran havenon raportas fermita dum la servilo estas tute sana, kaj tio estas la plej ofta falsa alarmo en ĉi tiu tuta kampo.

Nomoj aldonas ankoraŭ unu paŝon super la haveno. Se ludanto tajpas gastigan nomon, la solvado devas redoni la publikigitan adreson, kaj sur maŝino interne de la reto ĝi povas redoni privatan anstataŭe. Tio ne estas fiasko de fajroŝirmilo kaj neniu kvanto da plusendo de havenoj ŝanĝos ĝin.

Kial la ludanto interne sekvas alian vojon

Ludanto en la sama LAN, aŭ en VPN kiu atingas tiun LAN, provas atingi la publikan adreson de interne. La peto iras al la ekstera adreso de la kursentilo kaj la kursentilo devas traduki ĝin reen internen, kio estas la aranĝo kutime nomata hairpinning aŭ NAT-reflekto. Kaj la antaŭa traduko kaj la revena vojo devas kongrui por ke tio funkciu, kaj multaj hejmaj kursentiloj tute ne efektivigas ĝin.

Tial la gasto de ekstere aliĝas kaj la persono apud la servilo ne povas. La ekstera vojo estas vere en ordo; la interna flankenvojo estas tio, kio fiaskas, kaj ĝi fiaskas tiel, ke de la ekrano de la ludanto ĝi aspektas kiel servila problemo. La propra protokolo de la servilo decidas, kiu okazis, ĉar ligo, kiu neniam estis tradukita, neniam atingas ĝin.

Estas du honestaj riparoj kaj unu malbona kutimo. La bonaj elektoj estas lasi internajn ludantojn uzi la privatan adreson aŭ split-DNS-nomon kiu solviĝas interne al la privata adreso, aŭ ŝalti reflektion sur la kursentilo se la funkcio ekzistas kaj kondutas ĝuste. La malbona kutimo estas malfermi pli da havenoj aŭ malŝalti la gastigan fajroŝirmilon, kio ne povas efiki tradukon, kiun la kursentilo neniam faris.

La dokumentaro de Netgate pri NAT-reflekto priskribas pli detale la distingon inter ekstero kaj interno kaj la split-DNS-alternativon. Legu ĝin kiel priskribon de la mekanismo prefere ol kiel promeson, ke iu ajn konkreta VPN-provizanto aŭ kursentilo subtenas ĉiun loopback-variaĵon.

Kolektu pruvojn el ĉiu vidpunkto

Por ĉiu testo notu, kiu ĝin rulis, de kie, je kiu tempo, kontraŭ kiu adreso kaj haveno, kaj kion la servilo protokolis. Ludrifuzo kun klara kialo en la servila konzolo estas alia konkludo ol ligo, kiu neniam alvenis, kaj la du kondukas al kontraŭaj direktoj.

Se permesitaj foraj ludantoj aliĝas kaj unu loka ludanto ne povas, la loka vojo estas la restanta demando kaj ĝi meritas propran esploradon: kiun adreson la kliento uzis, kion la kursentilo faris kun la traduko, kaj ĉu la servilo registris iun ajn provon de ligo. Transdonu tiujn tri faktojn al tiu, kiu posedas la reton, anstataŭ remalfermi havenojn hazarde.