Il verificatore di porte dice aperto? Perché i giocatori di Minecraft ancora non riescono a entrare

Qualcuno esegue un controllo di porta, vede la parola aperto e considera il server risolto. Ciò che quel risultato significa davvero è ristretto: dalla posizione del verificatore, in quel momento, è stata accettata una connessione TCP verso quell’indirizzo e quella porta. Non dice nulla sullo scambio di saluti del protocollo Minecraft, sull’autenticazione dell’account né se il server abbia ammesso il giocatore in un mondo.

Sono quattro livelli diversi, e un guasto in uno qualsiasi di essi produce la stessa frase dal giocatore: non ha funzionato.

Una sonda verifica solo ciò che può vedere

Una connessione TCP si completa quando entrambe le parti terminano lo handshake a tre vie, che sta sotto tutto ciò che il gioco conosce. La sonda riferisce che esisteva un ascoltatore e che ha risposto dalla sua posizione di rete. Non può dirti che l’ascoltatore è il gioco, perché qualsiasi processo può occupare una porta e accettare connessioni.

La posizione conta quanto il risultato. Un verificatore su internet pubblico testa un percorso da una rete. Un verificatore che l’operatore esegue dall’interno della stessa rete testa un percorso del tutto diverso, e un risultato positivo lì non dice quasi nulla su ciò che sperimenta un giocatore remoto. Due verificatori diversi presso due fornitori diversi possono persino non essere d’accordo per motivi che non hanno nulla a che fare con il tuo server.

Anche il momento conta. Il risultato di una sonda descrive l’istante in cui è stata eseguita, e una connessione domestica con indirizzo dinamico o una regola di inoltro cambiata può spostare la risposta reale qualche minuto dopo. Annota l’indirizzo pubblico, la porta, la famiglia di indirizzi e l’ora insieme al verdetto, altrimenti l’osservazione non è riproducibile. Ripeti il controllo da una rete realmente diversa invece che da un telefono sulla stessa connessione.

Quattro livelli tra un socket e un giocatore

Immagina la sequenza che un client che si unisce esegue davvero. Prima risolve l’indirizzo, poi apre una connessione TCP alla porta pubblicata, poi parla il protocollo del gioco stesso per negoziare e autenticare, e infine il server decide se quell’identità può entrare nel mondo. Ogni livello ha la propria firma di guasto, e solo il primo è visibile a un verificatore di porte.

La porta predefinita di Java Edition è 25565, ma l’operatore può pubblicare una porta esterna diversa e inoltrarla verso l’interno, quindi il numero che un giocatore digita non è necessariamente il numero che vede il server. Un verificatore puntato sulla porta esterna sbagliata segnala chiuso mentre il server è perfettamente sano, e questo è il falso allarme più comune in tutto questo ambito.

I nomi aggiungono un altro passaggio sopra la porta. Se un giocatore digita un nome host, la risoluzione deve restituire l’indirizzo pubblicato, e su una macchina all’interno della rete può restituirne uno privato al suo posto. Non è un guasto del firewall e nessuna quantità di inoltro delle porte lo cambierà.

Perché il giocatore all’interno prende un percorso diverso

Un giocatore sulla stessa LAN, o su una VPN che raggiunge quella LAN, prova a raggiungere l’indirizzo pubblico dall’interno. La richiesta va all’indirizzo esterno del router e il router deve tradurla di nuovo verso l’interno, che è la disposizione comunemente chiamata hairpinning o riflessione NAT. Sia la traduzione in andata sia il percorso di ritorno devono allinearsi perché funzioni, e molti router domestici non lo implementano affatto.

Ecco perché l’ospite dall’esterno si unisce e la persona seduta accanto al server non può. Il percorso esterno è davvero a posto; è il giro interno che fallisce, e fallisce in un modo che dallo schermo del giocatore sembra un problema del server. Il registro del server stesso stabilisce quale dei due è successo, perché una connessione che non è mai stata tradotta non lo raggiunge mai.

Ci sono due correzioni oneste e una cattiva abitudine. Le buone opzioni sono lasciare che i giocatori interni usino l’indirizzo privato o un nome split-DNS che si risolve internamente all’indirizzo privato, oppure abilitare la riflessione sul router se la funzione esiste e si comporta bene. La cattiva abitudine è aprire più porte o disattivare il firewall dell’host, cosa che non può influire su una traduzione che il router non ha mai eseguito.

La documentazione Netgate sulla riflessione NAT descrive più in dettaglio la distinzione tra esterno e interno e l’alternativa split-DNS. Leggila come descrizione del meccanismo e non come promessa che un determinato fornitore VPN o router supporti ogni variante di loopback.

Raccogli prove da ogni punto di vista

Per ogni test, annota chi l’ha eseguito, da dove, a che ora, contro quale indirizzo e porta, e cosa ha registrato il server. Un rifiuto del gioco con un motivo chiaro nella console del server è una constatazione diversa da una connessione che non è mai arrivata, e le due portano in direzioni opposte.

Se i giocatori remoti autorizzati si uniscono e un giocatore locale non può, il percorso locale è la domanda rimasta e merita un’indagine propria: quale indirizzo ha usato il client, cosa ha fatto il router con la traduzione e se il server ha registrato qualche tentativo di connessione. Passa questi tre fatti a chi possiede la rete invece di riaprire porte a caso.