Portsjekken sier åpen? Hvorfor Minecraft-spillere fortsatt ikke får bli med

Noen kjører en portsjekk, ser ordet åpen og regner serveren som løst. Det resultatet faktisk betyr er smalt: fra sjekkens plassering, i det øyeblikket, ble en TCP-tilkobling til den adressen og porten godtatt. Det sier ingenting om håndtrykket i Minecraft-protokollen, kontobekreftelse eller om serveren slapp spilleren inn i en verden.

Det er fire forskjellige lag, og en feil i et av dem gir den samme setningen fra spilleren: det virket ikke.

En sonde tester bare det den kan se

En TCP-tilkobling fullføres når begge sider fullfører treveis-håndtrykket, som ligger under alt spillet vet om. Sonden rapporterer at det fantes en lytter, og at den svarte fra sin nettverksplassering. Den kan ikke fortelle deg at lytteren er spillet, fordi enhver prosess kan binde en port og godta tilkoblinger.

Plasseringen betyr like mye som resultatet. En sjekk på det åpne internettet tester én vei fra ett nettverk. En sjekk som operatøren kjører fra innsiden av det samme nettverket tester en helt annen vei, og et positivt resultat der sier nesten ingenting om det en ekstern spiller opplever. To forskjellige sjekker hos to forskjellige leverandører kan til og med være uenige av grunner som ikke har noe med serveren din å gjøre.

Tidspunktet betyr også noe. Et sondresultat beskriver øyeblikket det ble kjørt, og en hjemmetilkobling med dynamisk adresse eller endret videresendingsregel kan flytte det virkelige svaret noen minutter senere. Noter den offentlige adressen, porten, adressefamilien og tidspunktet sammen med dommen, ellers kan ikke observasjonen gjentas. Gjenta sjekken fra et virkelig annet nettverk i stedet for fra en telefon på samme tilkobling.

Fire lag mellom en socket og en spiller

Se for deg rekkefølgen en klient som blir med faktisk utfører. Først løser den opp adressen, deretter åpner den en TCP-tilkobling til den publiserte porten, deretter snakker den spillets eget protokoll for å forhandle og autentisere, og til slutt avgjør serveren om den identiteten får komme inn i verden. Hvert lag har sin egen feilsignatur, og bare det første er synlig for en portsjekk.

Standardporten for Java Edition er 25565, men operatøren kan publisere en annen ekstern port og videresende den innover, så tallet en spiller skriver inn er ikke nødvendigvis tallet serveren ser. En sjekk rettet mot feil ekstern port rapporterer lukket mens serveren er helt frisk, og det er den vanligste falske alarmen i hele dette området.

Navn legger til ett trinn over porten. Hvis en spiller skriver et vertsnavn, må oppslaget returnere den publiserte adressen, og på en maskin inne i nettverket kan det returnere en privat i stedet. Det er ikke en brannmurfeil, og ingen mengde portvideresending vil endre det.

Hvorfor spilleren innenfra tar en annen vei

En spiller på samme LAN, eller på en VPN som når det LAN-et, prøver å nå den offentlige adressen fra innsiden. Forespørselen går til ruterenes eksterne adresse, og ruteren må oversette den tilbake innover, noe som er ordningen som vanligvis kalles hairpinning eller NAT-refleksjon. Både oversettelsen utover og returveien må stemme for at det skal virke, og mange forbrukerrutere implementerer det ikke i det hele tatt.

Derfor kommer gjesten utenfra inn, mens personen ved siden av serveren ikke kan. Den eksterne veien er virkelig i orden; det er den interne omveien som svikter, og den svikter på en måte som fra spillerens skjerm ser ut som et serverproblem. Serverens egen logg avgjør hva som skjedde, fordi en tilkobling som aldri ble oversatt aldri når den.

Det finnes to ærlige rettelser og én dårlig vane. De gode alternativene er å la interne spillere bruke den private adressen eller et split-DNS-navn som løses internt til den private adressen, eller å aktivere refleksjon på ruteren hvis funksjonen finnes og oppfører seg riktig. Den dårlige vanen er å åpne flere porter eller slå av vertsbrannmuren, noe som ikke kan påvirke en oversettelse ruteren aldri utførte.

Netgate-dokumentasjonen om NAT-refleksjon beskriver forskjellen mellom utsiden og innsiden og split-DNS-alternativet mer detaljert. Les den som en beskrivelse av mekanismen og ikke som et løfte om at en bestemt VPN-leverandør eller ruter støtter hver loopback-variant.

Samle bevis fra hvert synspunkt

For hver test, skriv ned hvem som kjørte den, hvorfra, på hvilket tidspunkt, mot hvilken adresse og port, og hva serveren logget. En spillavvisning med klar årsak i serverkonsollen er et annet funn enn en tilkobling som aldri kom frem, og de to peker i motsatte retninger.

Hvis tillatte eksterne spillere blir med og én lokal spiller ikke kan, er den lokale veien det gjenstående spørsmålet, og den fortjener sin egen undersøkelse: hvilken adresse klienten brukte, hva ruteren gjorde med oversettelsen, og om serveren i det hele tatt registrerte noe tilkoblingsforsøk. Gi de tre fakta videre til den som eier nettverket, i stedet for å åpne porter på måfå.