Porttjek siger åben? Hvorfor Minecraft-spillere stadig ikke kan tilslutte

Nogen kører et porttjek, ser ordet åben og betragter serveren som løst. Det, resultatet faktisk betyder, er snævert: fra tjekkets placering, i det øjeblik, blev en TCP-forbindelse til den adresse og port accepteret. Det siger intet om Minecraft-protokollens håndtryk, kontobekræftelse eller om serveren lukkede spilleren ind i en verden.

Det er fire forskellige lag, og en fejl i et af dem giver den samme sætning fra spilleren: det virkede ikke.

En sonde tester kun det, den kan se

En TCP-forbindelse fuldføres, når begge sider afslutter trevejs-håndtrykket, som ligger under alt, hvad spillet ved. Sonden rapporterer, at der fandtes en lytter, og at den svarede fra sin netværksplacering. Den kan ikke fortælle dig, at lytteren er spillet, fordi enhver proces kan binde en port og acceptere forbindelser.

Placeringen betyder lige så meget som resultatet. Et tjek på det offentlige internet tester én vej fra ét netværk. Et tjek, som operatøren kører indefra det samme netværk, tester en helt anden vej, og et positivt resultat der siger næsten intet om, hvad en fjern spiller oplever. To forskellige tjek hos to forskellige udbydere kan endda være uenige af grunde, der intet har med din server at gøre.

Tidspunktet betyder også noget. Et sonderesultat beskriver det øjeblik, det kørte, og en hjemmeforbindelse med dynamisk adresse eller en ændret videresendelsesregel kan flytte det rigtige svar få minutter senere. Noter den offentlige adresse, porten, adressefamilien og tidspunktet sammen med dommen, ellers kan observationen ikke gentages. Gentag tjekket fra et virkelig anderledes netværk i stedet for fra en telefon på den samme forbindelse.

Fire lag mellem en socket og en spiller

Forestil dig den rækkefølge, en klient, der tilslutter sig, faktisk udfører. Først opløser den adressen, derefter åbner den en TCP-forbindelse til den offentliggjorte port, derefter taler den spillets egen protokol for at forhandle og bekræfte, og til sidst beslutter serveren, om den identitet må komme ind i verden. Hvert lag har sin egen fejlsignatur, og kun det første er synligt for et porttjek.

Standardporten for Java Edition er 25565, men operatøren kan offentliggøre en anden ekstern port og videresende den indad, så det tal, en spiller skriver, er ikke nødvendigvis det tal, serveren ser. Et tjek rettet mod den forkerte eksterne port rapporterer lukket, mens serveren er fuldstændig sund, og det er den mest almindelige falske alarm i hele dette område.

Navne tilføjer endnu et trin oven over porten. Hvis en spiller skriver et værtsnavn, skal opslaget returnere den offentliggjorte adresse, og på en maskine inde i netværket kan det i stedet returnere en privat. Det er ikke en firewallfejl, og ingen mængde portvideresendelse vil ændre det.

Hvorfor spilleren indenfor tager en anden vej

En spiller på det samme LAN, eller på en VPN der når det LAN, forsøger at nå den offentlige adresse indefra. Anmodningen går til routerens eksterne adresse, og routeren skal oversætte den tilbage indad, hvilket er den ordning, der normalt kaldes hairpinning eller NAT-refleksion. Både videresendelsen og returvejen skal passe sammen, for at det virker, og mange forbrugerroutere implementerer det slet ikke.

Det er derfor, gæsten udefra kan tilslutte sig, mens personen ved siden af serveren ikke kan. Den eksterne vej er virkelig i orden; den interne omvej er det, der fejler, og den fejler på en måde, der fra spillerens skærm ligner et serverproblem. Serverens egen log afgør, hvad der skete, fordi en forbindelse, der aldrig blev oversat, aldrig når den.

Der er to ærlige rettelser og én dårlig vane. De gode muligheder er at lade interne spillere bruge den private adresse eller et split-DNS-navn, der opløses internt til den private adresse, eller at aktivere refleksion på routeren, hvis funktionen findes og opfører sig korrekt. Den dårlige vane er at åbne flere porte eller slå værtsfirewallen fra, hvilket ikke kan påvirke en oversættelse, som routeren aldrig udførte.

Netgate-dokumentationen om NAT-refleksion beskriver forskellen mellem eksternt og internt og split-DNS-alternativet mere detaljeret. Læs den som en beskrivelse af mekanismen snarere end som et løfte om, at en bestemt VPN-udbyder eller router understøtter hver loopback-variant.

Indsaml beviser fra hvert synspunkt

For hver test skal du skrive ned, hvem der kørte den, hvorfra, på hvilket tidspunkt, mod hvilken adresse og port, og hvad serveren loggede. En spilafvisning med en klar årsag i serverkonsollen er et andet fund end en forbindelse, der aldrig nåede frem, og de to peger i modsatte retninger.

Hvis tilladte fjernspillere kan tilslutte sig, og én lokal spiller ikke kan, er den lokale vej det resterende spørgsmål, og den fortjener sin egen undersøgelse: hvilken adresse brugte klienten, hvad gjorde routeren med oversættelsen, og registrerede serveren overhovedet noget forbindelsesforsøg. Giv de tre fakta videre til den, der ejer netværket, i stedet for at åbne porte på må og få.