Verificatorul de porturi spune deschis? De ce jucătorii de Minecraft tot nu pot intra

Cineva rulează o verificare de port, vede cuvântul deschis și consideră serverul rezolvat. Ce înseamnă de fapt acel rezultat este îngust: din locația verificatorului, în acel moment, o conexiune TCP către acea adresă și acel port a fost acceptată. Nu spune nimic despre handshake-ul protocolului Minecraft, autentificarea contului sau dacă serverul a admis jucătorul într-o lume.

Sunt patru straturi diferite, iar o defecțiune în oricare dintre ele produce aceeași frază de la jucător: nu a funcționat.

O sondă testează doar ce poate vedea

O conexiune TCP se finalizează când ambele părți termină handshake-ul în trei pași, care se află sub tot ce știe jocul. Sonda raportează că a existat un ascultător și că a răspuns din locația sa de rețea. Nu îți poate spune că ascultătorul este jocul, pentru că orice proces poate ocupa un port și poate accepta conexiuni.

Locația contează la fel de mult ca rezultatul. Un verificator pe internetul public testează o cale dintr-o rețea. Un verificator pe care operatorul îl rulează din interiorul aceleiași rețele testează o cale complet diferită, iar un rezultat pozitiv acolo nu spune aproape nimic despre ce experimentează un jucător aflat la distanță. Doi verificatori diferiți la doi furnizori diferiți pot chiar să nu fie de acord din motive care nu au nimic de-a face cu serverul tău.

Și momentul contează. Rezultatul unei sonde descrie clipa în care a rulat, iar o conexiune de acasă cu adresă dinamică sau cu o regulă de redirecționare schimbată poate muta răspunsul real câteva minute mai târziu. Notează adresa publică, portul, familia de adrese și ora împreună cu verdictul, altfel observația nu poate fi reprodusă. Repetă verificarea dintr-o rețea cu adevărat diferită, nu de pe un telefon aflat pe aceeași conexiune.

Patru straturi între un socket și un jucător

Imaginează-ți secvența pe care un client care se conectează o execută de fapt. Mai întâi rezolvă adresa, apoi deschide o conexiune TCP către portul publicat, apoi vorbește protocolul propriu al jocului pentru a negocia și a se autentifica, iar în final serverul decide dacă acea identitate poate intra în lume. Fiecare strat are propria semnătură de eșec, iar doar primul este vizibil pentru un verificator de porturi.

Portul implicit pentru Java Edition este 25565, dar operatorul poate publica un alt port extern și îl poate redirecționa spre interior, așa că numărul pe care îl tastează un jucător nu este neapărat numărul pe care îl vede serverul. Un verificator îndreptat spre portul extern greșit raportează închis în timp ce serverul este perfect sănătos, iar aceasta este cea mai frecventă alarmă falsă din tot acest domeniu.

Numele adaugă încă un pas deasupra portului. Dacă un jucător tastează un nume de gazdă, rezolvarea trebuie să returneze adresa publicată, iar pe o mașină din interiorul rețelei poate returna una privată în schimb. Aceasta nu este o defecțiune a firewall-ului și nicio cantitate de redirecționare a porturilor nu o va schimba.

De ce jucătorul din interior ia o altă cale

Un jucător din același LAN, sau dintr-un VPN care ajunge la acel LAN, încearcă să atingă adresa publică din interior. Cererea merge către adresa externă a routerului, iar routerul trebuie să o traducă înapoi spre interior, ceea ce este aranjamentul numit de obicei hairpinning sau reflexie NAT. Atât traducerea înainte, cât și calea de întoarcere trebuie să se potrivească pentru ca asta să funcționeze, iar multe routere de consum nu implementează deloc acest lucru.

De aceea oaspetele din exterior se conectează, iar persoana de lângă server nu poate. Calea externă este într-adevăr în regulă; ocolul intern este cel care eșuează, și eșuează într-un mod care, de pe ecranul jucătorului, arată ca o problemă a serverului. Logul serverului însuși decide care dintre cele două s-a întâmplat, pentru că o conexiune care nu a fost niciodată tradusă nu ajunge niciodată la el.

Există două corecturi cinstite și un obicei prost. Opțiunile bune sunt să lași jucătorii interni să folosească adresa privată sau un nume split-DNS care se rezolvă intern la adresa privată, sau să activezi reflexia pe router dacă funcția există și se comportă corect. Obiceiul prost este să deschizi mai multe porturi sau să dezactivezi firewall-ul gazdei, ceea ce nu poate afecta o traducere pe care routerul nu a făcut-o niciodată.

Documentația Netgate despre reflexia NAT descrie mai detaliat distincția dintre exterior și interior și alternativa split-DNS. Citește-o ca o descriere a mecanismului, nu ca o promisiune că un anumit furnizor de VPN sau router suportă fiecare variantă de loopback.

Adună dovezi din fiecare punct de vedere

Pentru fiecare test, notează cine l-a rulat, de unde, la ce oră, împotriva cărei adrese și port, și ce a înregistrat serverul. O respingere a jocului cu un motiv clar în consola serverului este o constatare diferită de o conexiune care nu a ajuns niciodată, iar cele două duc în direcții opuse.

Dacă jucătorii la distanță permisi se conectează, iar un jucător local nu poate, calea locală este întrebarea rămasă și merită propria investigație: ce adresă a folosit clientul, ce a făcut routerul cu traducerea și dacă serverul a înregistrat măcar vreo încercare de conexiune. Predă aceste trei fapte celui care deține rețeaua, în loc să redeschizi porturi la întâmplare.