Porttiskanneri sanoo auki? Miksi Minecraft-pelaajat eivät silti pääse liittymään

Joku ajaa porttitarkistuksen, näkee sanan auki ja pitää palvelinta ratkaistuna. Mitä tulos itse asiassa tarkoittaa, on kapeaa: tarkistajan sijainnista, sillä hetkellä, TCP-yhteys tuohon osoitteeseen ja porttiin hyväksyttiin. Se ei kerro mitään Minecraft-protokollan kättelystä, tilin tunnistamisesta tai siitä, päästikö palvelin pelaajan maailmaan.

Nämä ovat neljä eri kerrosta, ja epäonnistuminen missä tahansa niistä tuottaa pelaajalta saman lauseen: se ei toiminut.

Anturi testaa vain sen, minkä se näkee

TCP-yhteys valmistuu, kun molemmat osapuolet saavat kolmisuuntaisen kättelyn valmiiksi, ja se on kaiken pelin tietämän alapuolella. Anturi raportoi, että kuuntelija oli olemassa ja vastasi omasta verkkosijainnistaan. Se ei voi kertoa sinulle, että kuuntelija on peli, koska mikä tahansa prosessi voi varata portin ja hyväksyä yhteyksiä.

Sijainti merkitsee yhtä paljon kuin tulos. Julkisessa internetissä oleva tarkistaja testaa yhtä reittiä yhdestä verkosta. Tarkistaja, jonka ylläpitäjä ajaa saman verkon sisältä, testaa täysin toista reittiä, eikä positiivinen tulos siellä kerro juuri mitään siitä, mitä etäinen pelaaja kokee. Kaksi eri tarkistajaa kahdella eri palveluntarjoajalla voivat jopa olla eri mieltä syistä, joilla ei ole mitään tekemistä palvelimesi kanssa.

Myös ajoitus merkitsee. Anturin tulos kuvaa hetkeä, jolloin se ajettiin, ja kodin yhteys, jossa on dynaaminen osoite tai muuttunut edelleenohjaussääntö, voi siirtää todellista vastausta muutaman minuutin myöhemmäksi. Kirjaa julkinen osoite, portti, osoiteperhe ja aika yhdessä tuomion kanssa, muuten havainto ei ole toistettavissa. Toista tarkistus aidosti eri verkosta, älä samassa yhteydessä olevasta puhelimesta.

Neljä kerrosta socketin ja pelaajan välissä

Kuvittele järjestys, jonka liittyvä asiakas tosiasiassa suorittaa. Ensin se selvittää osoitteen, sitten se avaa TCP-yhteyden julkaistuun porttiin, sitten se puhuu pelin omaa protokollaa neuvotellakseen ja tunnistautuakseen, ja lopuksi palvelin päättää, päästetäänkö tämä identiteetti maailmaan. Jokaisella kerroksella on oma vikasignatuurinsa, ja vain ensimmäinen on porttitarkistajalle näkyvä.

Java Editionin oletusportti on 25565, mutta ylläpitäjä voi julkaista toisen ulkoisen portin ja ohjata sen sisäänpäin, joten pelaajan kirjoittama numero ei välttämättä ole se numero, jonka palvelin näkee. Väärään ulkoiseen porttiin suunnattu tarkistaja ilmoittaa suljetuksi, vaikka palvelin on täysin terve, ja se on yleisin väärä hälytys koko tällä alueella.

Nimet lisäävät vielä yhden askeleen portin yläpuolelle. Jos pelaaja kirjoittaa isäntänimen, selvityksen on palautettava julkaistu osoite, ja verkossa olevalla koneella se voi palauttaa sen sijaan yksityisen. Se ei ole palomuurin vika, eikä mikään määrä portinohjausta muuta sitä.

Miksi sisällä oleva pelaaja kulkee eri reittiä

Pelaaja samassa lähiverkossa tai VPN:ssä, joka yltää siihen lähiverkkoon, yrittää tavoittaa julkisen osoitteen sisältä. Pyyntö menee reitittimen ulkoiseen osoitteeseen, ja reitittimen on käännettävä se takaisin sisäänpäin, mikä on järjestely, jota yleensä kutsutaan hairpinningiksi eli NAT-heijastukseksi. Sekä edelleenkäännöksen että paluureitin on osuttava kohdalleen, jotta se toimisi, eivätkä monet kuluttajareitittimet toteuta sitä lainkaan.

Siksi ulkopuolinen vieras liittyy ja palvelimen vieressä istuva henkilö ei pääse. Ulkoinen reitti on todella kunnossa; sisäinen kiertotie on se, joka epäonnistuu, ja se epäonnistuu niin, että pelaajan ruudulta se näyttää palvelinongelmalta. Palvelimen oma loki ratkaisee, kumpi tapahtui, koska yhteys, jota ei koskaan käännetty, ei koskaan saavu sinne.

On kaksi rehellistä korjausta ja yksi huono tapa. Hyvät vaihtoehdot ovat antaa sisäisten pelaajien käyttää yksityistä osoitetta tai split-DNS-nimeä, joka selviää sisäisesti yksityiseksi osoitteeksi, tai ottaa heijastus käyttöön reitittimessä, jos ominaisuus on olemassa ja käyttäytyy oikein. Huono tapa on avata lisää portteja tai kytkeä isäntäkoneen palomuuri pois, mikä ei voi vaikuttaa käännökseen, jota reititin ei koskaan tehnyt.

Netgaten NAT-heijastusta koskeva dokumentaatio kuvaa yksityiskohtaisemmin ulkoisen ja sisäisen eron ja split-DNS-vaihtoehdon. Lue se kuvauksena mekanismista, älä lupauksena siitä, että jokin tietty VPN-palveluntarjoaja tai reititin tukee kaikkia loopback-muunnelmia.

Kerää todisteita jokaisesta näkökulmasta

Kirjaa jokaisesta testistä, kuka sen ajoi, mistä, mihin aikaan, mitä osoitetta ja porttia vastaan, ja mitä palvelin lokiin kirjasi. Pelin hylkäys, jossa on selkeä syy palvelinkonsolissa, on eri havainto kuin yhteys, joka ei koskaan saapunut, ja ne johtavat vastakkaisiin suuntiin.

Jos sallitut etäpelaajat liittyvät ja yksi paikallinen pelaaja ei pääse, paikallinen reitti on jäljellä oleva kysymys ja ansaitsee oman selvityksensä: mitä osoitetta asiakas käytti, mitä reititin teki käännökselle ja kirjasiko palvelin ylipäätään mitään yhteydenottoyritystä. Anna nämä kolme tosiasiaa verkon omistajalle sen sijaan, että avaat portteja umpimähkään.