Portsjekken seier open? Kvifor Minecraft-spelarar framleis ikkje får bli med

Nokon køyrer ein portsjekk, ser ordet open og reknar serveren som løyst. Det resultatet faktisk tyder er smalt: frå plasseringa til sjekken, i det augneblunken, vart ei TCP-tilkopling til den adressa og den porten godteken. Det seier ingenting om handtrykket i Minecraft-protokollen, kontobekrefting eller om serveren sleppte spelaren inn i ei verd.

Det er fire ulike lag, og ein feil i eit av dei gir den same setninga frå spelaren: det verka ikkje.

Ein sonde testar berre det han kan sjå

Ei TCP-tilkopling vert fullført når begge sider fullfører trevegs-handtrykket, som ligg under alt spelet veit om. Sonden rapporterer at det fanst ein lyttar, og at han svara frå nettverksplasseringa si. Han kan ikkje fortelje deg at lyttaren er spelet, fordi kvar prosess kan binda ein port og ta imot tilkoplingar.

Plasseringa tyder like mykje som resultatet. Ein sjekk på det opne internettet testar éin veg frå eitt nettverk. Ein sjekk som operatøren køyrer frå innsida av det same nettverket testar ein heilt annan veg, og eit positivt resultat der seier nesten ingenting om det ein ekstern spelar opplever. To ulike sjekkar hos to ulike leverandørar kan til og med vere usamde av grunnar som ikkje har noko med serveren din å gjere.

Tidspunktet tyder også noko. Eit sondsvar skildrar augneblunken det vart køyrt, og ei heimetilkopling med dynamisk adresse eller endra vidaresendingsregel kan flytta det verkelege svaret nokre minutt seinare. Noter den offentlege adressa, porten, adressefamilien og tidspunktet saman med dommen, elles kan ikkje observasjonen gjerast om att. Gjenta sjekken frå eit verkeleg anna nettverk i staden for frå ein telefon på same tilkopling.

Fire lag mellom ein socket og ein spelar

Sjå føre deg rekkjefølgja ein klient som blir med faktisk utfører. Fyrst løyser han opp adressa, deretter opnar han ei TCP-tilkopling til den publiserte porten, deretter snakkar han spelet sitt eige protokoll for å forhandla og autentisere, og til slutt avgjer serveren om den identiteten får kome inn i verda. Kvart lag har sin eigen feilsignatur, og berre det fyrste er synleg for ein portsjekk.

Standardporten for Java Edition er 25565, men operatøren kan publisere ein annan ekstern port og vidaresende han innover, så talet ein spelar skriv inn er ikkje nødvendigvis talet serveren ser. Ein sjekk retta mot feil ekstern port rapporterer lukka medan serveren er heilt frisk, og det er den vanlegaste falske alarmen i heile dette området.

Namn legg til eit steg over porten. Viss ein spelar skriv eit vertsnamn, må oppslaget returnere den publiserte adressa, og på ein maskin inne i nettverket kan det returnere ei privat adresse i staden. Det er ikkje ein brannmurfeil, og inga mengd portvidaresending vil endre det.

Kvifor spelaren innanfrå tek ein annan veg

Ein spelar på same LAN, eller på ein VPN som når det LAN-et, prøver å nå den offentlege adressa frå innsida. Førespurnaden går til den eksterne adressa til rutaren, og rutaren må omsetje han tilbake innover, noko som er ordninga som vanlegvis blir kalla hairpinning eller NAT-refleksjon. Både omsetjinga utover og returvegen må stemme for at det skal verke, og mange forbrukarrutarar implementerer det ikkje i det heile.

Derfor kjem gjesten utanfrå inn, medan personen ved sida av serveren ikkje kan. Den eksterne vegen er verkeleg i orden; det er den interne omvegen som sviktar, og han sviktar på ein måte som frå skjermen til spelaren ser ut som eit serverproblem. Loggen til serveren sjølv avgjer kva som hende, fordi ei tilkopling som aldri vart omsett aldri når han.

Det finst to ærlege rettingar og éin dårleg vane. Dei gode alternativa er å la interne spelarar bruke den private adressa eller eit split-DNS-namn som blir løyst internt til den private adressa, eller å slå på refleksjon på rutaren viss funksjonen finst og oppfører seg rett. Den dårlege vanen er å opne fleire portar eller slå av vertsbrannmuren, noko som ikkje kan påverke ei omsetjing rutaren aldri utførte.

Netgate-dokumentasjonen om NAT-refleksjon skildrar skiljet mellom utsida og innsida og split-DNS-alternativet meir detaljert. Les han som ei skildring av mekanismen og ikkje som eit løfte om at ein bestemt VPN-leverandør eller rutar støttar kvar loopback-variant.

Samle bevis frå kvart synspunkt

For kvar test, skriv ned kven som køyrde han, kvarfrå, på kva tidspunkt, mot kva adresse og port, og kva serveren logga. Ei avvising av spelet med klar grunn i serverkonsollen er eit anna funn enn ei tilkopling som aldri kom fram, og dei to peikar i motsette retningar.

Viss tillatne eksterne spelarar blir med og éin lokal spelar ikkje kan, er den lokale vegen det gjenverande spørsmålet, og han fortener si eiga undersøking: kva adresse klienten brukte, kva rutaren gjorde med omsetjinga, og om serveren i det heile registrerte noko tilkoplingsforsøk. Gi dei tre fakta vidare til den som eig nettverket, i staden for å opne portar på måfå.