De poortchecker zegt open? Waarom Minecraft-spelers toch niet kunnen deelnemen

Iemand laat een poortcheck lopen, ziet het woord open en beschouwt de server als opgelost. Wat dat resultaat werkelijk betekent, is smal: vanaf de locatie van de checker, op dat moment, werd een TCP-verbinding naar dat adres en die poort geaccepteerd. Het zegt niets over de handshake van het Minecraft-protocol, accountverificatie of het feit of de server de speler tot een wereld toeliet.

Dat zijn vier verschillende lagen, en een fout in een ervan levert bij de speler dezelfde zin op: het werkte niet.

Een probe test alleen wat hij kan zien

Een TCP-verbinding komt tot stand wanneer beide kanten de drie-weg-handshake afronden, die onder alles ligt wat het spel weet. De probe meldt dat er een luisteraar bestond en dat die vanaf zijn netwerklocatie antwoordde. Hij kan je niet vertellen dat de luisteraar het spel is, want elk proces kan een poort binden en verbindingen accepteren.

De locatie is even belangrijk als het resultaat. Een checker op het openbare internet test één pad vanaf één netwerk. Een checker die de beheerder van binnen hetzelfde netwerk draait, test een heel ander pad, en een positief resultaat daar zegt bijna niets over wat een externe speler ervaart. Twee verschillende checkers bij twee verschillende providers kunnen het zelfs oneens zijn om redenen die niets met jouw server te maken hebben.

Ook de timing is belangrijk. Een proberesultaat beschrijft het moment waarop het liep, en een thuisverbinding met een dynamisch adres of een gewijzigde doorstuurregel kan het echte antwoord enkele minuten later verschuiven. Noteer het openbare adres, de poort, de adresfamilie en de tijd samen met het oordeel, anders is de waarneming niet reproduceerbaar. Herhaal de check vanaf een werkelijk ander netwerk in plaats van vanaf een telefoon op dezelfde verbinding.

Vier lagen tussen een socket en een speler

Stel je de volgorde voor die een deelnemende client werkelijk uitvoert. Eerst lost hij het adres op, dan opent hij een TCP-verbinding naar de gepubliceerde poort, dan spreekt hij het eigen protocol van het spel om te onderhandelen en te verifiëren, en ten slotte beslist de server of die identiteit de wereld in mag. Elke laag heeft zijn eigen faalhandtekening, en alleen de eerste is zichtbaar voor een poortchecker.

De standaardpoort voor Java Edition is 25565, maar de beheerder kan een andere externe poort publiceren en die naar binnen doorsturen, dus het nummer dat een speler typt is niet noodzakelijk het nummer dat de server ziet. Een checker die op de verkeerde externe poort is gericht, meldt gesloten terwijl de server volkomen gezond is, en dat is de meest voorkomende valse melding in dit hele gebied.

Namen voegen nog een stap boven de poort toe. Als een speler een hostnaam typt, moet de resolutie het gepubliceerde adres teruggeven, en op een machine binnen het netwerk kan het in plaats daarvan een privéadres teruggeven. Dat is geen firewallfout en geen enkele hoeveelheid poortdoorsturing zal dat veranderen.

Waarom de speler binnen een ander pad neemt

Een speler op hetzelfde LAN, of op een VPN die dat LAN bereikt, probeert het openbare adres van binnenuit te bereiken. Het verzoek gaat naar het externe adres van de router en de router moet het terug naar binnen vertalen, wat de opstelling is die gewoonlijk hairpinning of NAT-reflectie wordt genoemd. Zowel de heenvertaling als de terugweg moet kloppen om dat te laten werken, en veel consumentenrouters implementeren het helemaal niet.

Daarom komt de gast van buiten binnen en kan de persoon naast de server dat niet. Het externe pad is echt in orde; de interne omweg is wat faalt, en hij faalt op een manier die vanaf het scherm van de speler op een serverprobleem lijkt. Het eigen log van de server beslist wat er gebeurde, want een verbinding die nooit is vertaald bereikt hem nooit.

Er zijn twee eerlijke oplossingen en één slechte gewoonte. De goede opties zijn interne spelers het privéadres of een split-DNS-naam laten gebruiken die intern naar het privéadres oplost, of reflectie op de router inschakelen als de functie bestaat en zich goed gedraagt. De slechte gewoonte is meer poorten openen of de hostfirewall uitschakelen, wat geen invloed kan hebben op een vertaling die de router nooit heeft uitgevoerd.

De Netgate-documentatie over NAT-reflectie beschrijft het verschil tussen buiten en binnen en het split-DNS-alternatief in meer detail. Lees het als een beschrijving van het mechanisme en niet als een belofte dat een specifieke VPN-provider of router elke loopback-variant ondersteunt.

Verzamel bewijs vanuit elk gezichtspunt

Schrijf bij elke test op wie hem heeft uitgevoerd, van waar, op welk tijdstip, tegen welk adres en welke poort, en wat de server heeft gelogd. Een afwijzing van het spel met een duidelijke reden in de serverconsole is een andere bevinding dan een verbinding die nooit aankwam, en de twee wijzen in tegengestelde richtingen.

Als toegestane externe spelers deelnemen en één lokale speler niet kan, is het lokale pad de resterende vraag en dat verdient zijn eigen onderzoek: welk adres de client gebruikte, wat de router met de vertaling deed, en of de server überhaupt een verbindingspoging registreerde. Geef die drie feiten aan wie het netwerk bezit in plaats van poorten willekeurig opnieuw te openen.