Porttovábbítás Minecraft szerverhez: nyisd meg, javítsd vagy hagyd ki

Kezdd itt: melyik eset a tiéd?

Négy helyzet, négy különböző válasz. Keresd meg a sajátodat és ugorj oda — az okok alig fedik egymást, így a rossz ág elolvasásával egy estét dobsz ki.

A kétperces ellenőrzés, amit érdemes elsőként elvégezni

Egyetlen dolog dönti el, hogy a porttovábbítás egyáltalán működhet-e nálad, és két percbe telik. Csináld meg, mielőtt egyetlen router-beállításhoz is hozzáérsz, mert ha rossz eredményt hoz, ezen az oldalon az első ág egyik lépése sem segít.

1. Nyisd meg a routered adminfelületét és keresd meg, milyen WAN- vagy internetcímet mond magáénak. Az állapot- vagy áttekintő képernyőn van, általában WAN IP, Internet IP vagy IPv4 address néven.
2. Keress rá a "what is my IP" kifejezésre egy böngészőben, ugyanezen a hálózaton, és jegyezd fel a kapott címet.
3. Hasonlítsd össze a kettőt. Ha megegyeznek, valódi nyilvános címed van, és a porttovábbítás működni fog, amint helyesen beállítottad. Ha nem egyeznek, a szolgáltatód fordítja a forgalmadat, és a saját routereden megnyitott port nem éri el az internetet — a miért nem működött részben találod, mit tehetsz ilyenkor.

Továbbítsd rendesen a portot

Minden router menüje másképp épül fel, és a funkciónak több neve is van — Port Forwarding, Virtual Server, NAT Forwarding, Applications and Gaming. Az viszont mindenhol ugyanaz, aminek történnie kell: megmondod a routernek, hogy a Minecraft portján érkező forgalmat adja át annak a gépnek, amelyiken a szerver fut.

1. Először adj a szervergépnek fix helyi címet. Ezt a lépést szokták kihagyni, és emiatt áll le a továbbítás egy héttel később. A router ideiglenesen osztja a helyi címeket, így az a gép, ami ma 192.168.1.42, egy újraindítás után lehet 192.168.1.57 — a szabály viszont továbbra is a régire mutat. Vagy a routerben oldd meg, DHCP-foglalással az adott gépre, vagy magán a gépen, statikus címmel a router DHCP-tartományán kívül. A foglalás a biztonságosabb, mert így a router marad az egyetlen igazságforrás.
2. Hozd létre a továbbítási szabályt. A belső és a külső port is a szerver portjára állítva. Protokoll: TCP a Java esetén (25565), UDP a Bedrock esetén (19132). Cél: az imént rögzített helyi cím. Ha a router porttartományt vár, írd ugyanazt a számot a kezdő és a záró mezőbe is.
3. Engedd át a gép tűzfalán is. A router immár átküldi a forgalmat a gépre, a gép saját tűzfala viszont még mindig eldobhatja. Windowson vegyél fel bejövő szabályt a portra — vagy a szervert futtató Java programra — a Windows Defender Firewall alatt. Ez a második leggyakoribb oka annak, hogy egy helyes továbbítás látszólag semmit sem csinál.
4. Teszteld a hálózatodon kívülről. Ne a nappaliban lévő böngészőből. Kapcsold ki a Wi-Fit egy telefonon, hogy mobilneten legyen, és próbáld meg elérni a címet, vagy használj online port checkert, amíg a szerver fut. Mindkettő ugyanazt teszteli: hogy a külvilág be tud-e jutni.

Ha a külső ellenőrzés sikeres, a barátaid a nyilvános címeddel és a porttal csatlakoznak — Java esetén your.public.ip:25565. Ha a szolgáltatód időnként megváltoztatja a nyilvános címedet, ahogy a legtöbb lakossági kapcsolatnál történik, egy ingyenes dynamic DNS név fix hostnevet ad, ami követi a változást.

Továbbítottad, és még mindig nem működik

Haladj végig a listán sorrendben. Aszerint van rendezve, hogy melyik szokott leggyakrabban a megoldás lenni, és az első kettőt ingyen ki lehet zárni.

1. A saját hálózatodon belülről teszteltél

Fentebb már szó volt róla, és tényleg ez a leggyakoribb vaklárma: a hairpinning kötelező a szabványban, mégis sok router figyelmen kívül hagyja, így a nyilvános cím tesztelése a saját nappalidból egy tökéletesen működő beállításnál is elbukhat. Teszteld újra mobilnetről, mielőtt bármi máshoz hozzányúlnál.

2. Megváltozott a szervergép helyi címe

Ha működött, aztán leállt, szinte mindig ez az ok. A szabály olyan címre mutat, ami már nem a gépé. Vegyél fel DHCP-foglalást, hogy ne csúszhasson el újra.

3. Szolgáltatói szintű NAT — az, amire nincs kerülőút

Ha a routeredben látható WAN-cím nem egyezik azzal, amit a "what is my IP" mutat, akkor a forgalmadat a szolgáltatód fordítja, mielőtt kijutna az internetre, és a saját routereden megnyitott port a külvilág számára egyszerűen nem létezik. Ezt közvetlenül leolvashatod a routerről:

A szolgáltatói szintű NAT azért létezik, mert nincs elég IPv4-cím ahhoz, hogy minden háztartás kapjon egyet, így a szolgáltatók egyetlen nyilvános címet osztanak meg sok ügyfél között. Ez nem hiba, és senki nem csinált semmit rosszul. A lehetőségeid: kérj a szolgáltatódtól nyilvános IPv4-címet — sokan adnak, néha ingyen, néha fizetős kiegészítőként —, vagy szüntesd meg az igényt rá, akár egy alagúttal, akár egy hosztolt szerverrel.

4. Dupla NAT: két router, egy lánc

A routered WAN oldalán lévő privát cím azt jelenti, hogy a routered egy másik routerbe van bekötve — jellemzően a szolgáltatótól kapott dobozba, ami router módban fut, nem sima modemként. A szabályod helyes; csak a második eszköznél megáll. Három kiút, a legjobbal kezdve: tedd a szolgáltató dobozát bridge mode vagy modem mode állapotba, hogy a routered kapja meg közvetlenül a nyilvános címet; vagy továbbítsd ugyanazt a portot másodszor is a fölötted lévő eszközön, a routered felé; vagy tedd át a szervert a fölötted lévő eszköz mögé.

5. A gép saját tűzfala

A router továbbít, a gép eldob. Vegyél fel bejövő szabályt a portra vagy a szerver programjára, és teszteld újra kívülről.

6. Rossz protokoll vagy rossz port

A Java TCP 25565, a Bedrock UDP 19132. Nem felcserélhetők, és egy TCP-továbbítás mögött lévő Bedrock szerver elérhetetlen, miközben belülről teljesen egészségesnek látszik. Ha a szervered Bedrock, a beállítás nem csak a portban tér el — a Bedrock szerver útmutató végigveszi az egészet.

Biztonságos a porttovábbítás?

A rövid válasz: egyetlen portot megnyitni egy naprakészen tartott szerverhez rendben van, és pontosan ezt csinálja minden Minecraft szerver az interneten. A kockázat nem maga a nyitott port — hanem az, ami mögötte figyel, és az, hogy az otthoni címed mostantól a szerver címe. Mindkettő kezelhető, és egyik sem ok arra, hogy megijedj.

Mit csinál valójában egy nyitott port

Egy továbbított port pontosan egy programot tesz elérhetővé az internet felől: azt, amelyik azon a porton figyel. Nem nyitja meg a géped, a fájljaidat vagy a ház többi eszközét. Azt viszont jelenti, hogy aki megtalálja a címet, bármit küldhet annak az egy programnak — tehát a mögötte lévő szoftvernek olyannak kell lennie, amit naprakészen tartasz.

A valódi példa, pontosan elmondva

Az a Minecraft-példa, amihez mindenki nyúl, a Log4Shell — CVE-2021-44228, 10.0-s kritikus besorolással, 2021. december 10-én közzétéve —, és a Mojang még aznap kiadott egy közleményt, amiben megerősítette, hogy a Java Edition érintett. Érdemes pontosnak lenni abban, hogyan is működött, mert a közkeletű változat pont ott téved, ahol itt számít.

A Microsoft saját elemzése úgy írja le a támadást, hogy a támadó csatlakozott egy sérülékeny szerverhez és elküldött egy erre a célra összeállított játékon belüli üzenetet, ami aztán kódot futtatott a szerveren és a csatlakozott sérülékeny klienseken. Mindkét irány valós volt. De minden dokumentált esetben a támadónak csatlakoznia és interakcióba lépnie kellett — a nyitott port önmagában semmit nem futtatott. A tanulság nem az, hogy "ne nyiss portot", hanem az, hogy "tartsd naprakészen azt, ami a port mögött van", ami akkoriban az 1.18.1-re való átállást vagy a Mojang által régebbi verziókhoz közzétett kapcsoló használatát jelentette.

A költség, amire nincs javítás

A legtöbb gondolkodást igénylő rész egyáltalán nem sérülékenység: a nyilvános címed lesz a szerver címe, és mindenki, akit meghívsz, birtokolja — velük együtt mindenki, akinek továbbadják. Egy hosztolt szerver ellen irányuló szolgáltatásmegtagadási támadás azt a szervert éri; egy otthoni kapcsolat ellen irányuló az egész háztartást leveszi az internetről, és a te oldaladról nem tudod szűrni, mert a vonal már telített. Egy címet nem lehet visszavonni, ha egyszer kikerült. Az üzemidő-útmutató elmagyarázza, mit jelent ez hosszabb távon; a gyakorlati összefoglaló az, hogy öt barátnál ez jó üzlet, egy nyilvános szervernél viszont rossz.

Mitől lesz tényleg biztonságos

Tartsd a szervert friss verzión, kapcsold be a whitelistet, hogy csak a meghívottak léphessenek be, hagyd az online-mode beállítást az alapértéken, hogy a fiókok ellenőrizve legyenek, és készíts mentést a világról, mielőtt kísérletezel. Ez a négy az egész ellenőrzőlista, és a szervertelepítési útmutató biztonsági beállításokról szóló részében ott vannak a pontos értékek. Ha ezeket megcsinálod, egy továbbított port teljesen hétköznapi dolog.

Hogyan engedd be a barátaidat portnyitás nélkül

Az alagút olyan címet ad a külvilágnak, ami az alagút szolgáltatójáé, majd onnan viszi a forgalmat a gépeden futó szerverhez egy olyan kapcsolaton keresztül, amit a géped kifelé nyitott. A routeren semmi nem változik, ezért működik szolgáltatói szintű NAT mögött is, ahol a porttovábbítás nem tud. A cserébe kapott hátrány, hogy mostantól egy harmadik fél ül az útvonalon, az ingyenes csomagoknak pedig valódi korlátaik vannak.

A három név, amire keresni szoktak, azzal együtt, amit ma a saját dokumentációjuk mond:

playit.gg

Ez az, amelyik mindkét kiadást lefedi. A Java és a Bedrock is beépített előbeállítás az ingyenes szinten, tehát egy UDP-n futó Bedrock szerver fizetés nélkül működik — ami szokatlan, és ez a fő ok, amiért ezt érdemes választani. A játékosaid a playit által kiosztott címet kapják, nem a tiédet, és csak neked kell bármit telepítened. Az őszinte korlátok: az ingyenes alagutak megosztott globális útvonalon mennek, és a playit saját dokumentációja figyelmeztet, hogy egy játékost távoli adatközpontba is küldhet, az útvonalat négy ugrásként írva le, amelyek késleltetése összeadódik; a régió kiválasztása és a saját domain fizetős. Az ingyenes fiókok négy portot foglalhatnak.

ngrok

Javához jó, Bedrockhoz használhatatlan — az ngrok HTTP, HTTPS, TCP és TLS protokollt támogat, és nyíltan kimondja, hogy UDP-t nem. Két ingyenes szintű részlet buktat el, ha senki nem figyelmeztet: egy nyers TCP végpont megnyitásához fizetési módot kell megadni a fiókon, még ha ingyenes is marad, a címet pedig az alagút minden indításakor véletlenszerűen osztja ki, tehát a barátaidnak minden alkalommal új kell, hacsak nem fizetsz fenntartott címért. Egy mítosz, amit itt nyugdíjazhatunk: az a széles körben ismételt állítás, hogy az ingyenes ngrok alagutak két óra után leállnak, elavult — az ngrok jelenlegi dokumentációja szerint az ingyenes végpontok korlátlan ideig online maradhatnak.

Hamachi

A három közül a legrégebbi, és az egyetlen, ami másképp működik: nem egy nyilvános címhez vezető alagút, hanem virtuális LAN. Mindenki ugyanabba a privát hálózatba lép be, aztán úgy csatlakozik, mintha egy szobában lennének. Ez a különbség maga a történet, mindkét irányban.

Még mindig működik — a GoTo Group üzemelteti a LogMeIn márkanév alatt, és a kiadási jegyzetekben 2026-os bejegyzések is vannak —, és az ingyenes szint is létezik, de egy hálózatot öt tagra, veled együtt korlátoz. Négy barát. És a playit.gg-vel vagy az ngrokkal ellentétben minden játékos telepíti a klienst és belép a hálózatba, ami egy tinédzsercsapatnál rendszerint az a pont, ahol a terv elhal. Technikai oldalon teljes értékű virtuális hálózati adapter, és alapból UDP-n közvetíti a kapcsolatokat, tehát nem korlátozódik TCP-re — a GoTo dokumentációja viszont soha nem említi a Minecraftot, a Bedrockot vagy a 19132-es portot, ezért a Hamachin keresztüli Bedrockot kezeld teszteletlennek, ne támogatottnak. A GoTo a saját súgóoldalain arra is figyelmeztet, hogy a "high-speed, low-latency LAN environments" környezetre készült alkalmazások gyengén teljesíthetnek rajta.

Mibe kerül egy alagút

Főleg késleltetésbe. Az a forgalom, ami egyenesen a lakásodhoz ment volna, most először a szolgáltatóhoz megy, és ingyenes szinten ritkán választhatod meg, hogy az hol van. Egy ötfős survival világnál ezt senki nem veszi észre; bárminél, ahol az időzítés számít, igen. A másik költség, hogy a szervered elérhetősége mostantól attól függ, hogy egy harmadik fél ingyenes csomagja fennmarad-e ugyanezekkel a feltételekkel — ami, ahogy a fenti alagutak mutatják, nem magától értetődő.

Amikor a hosztolt szerver az őszinte válasz

Nem minden olvasónak van erre szüksége, és mást állítani tisztességtelen lenne — rengetegen éveken át futtatnak jó szervert egy tartalék gépen. De van négy helyzet, amiben a fenti küzdelem nem nyerhető meg vagy nem éri meg, és jobb ezt kimondani, mint hagyni, hogy olyan routert hangolj, ami nem tud segíteni:

• Szolgáltatói szintű NAT mögött vagy. Ez az, amire a routernél nincs kerülőút. Az alagút és a hosztolt szerver az egyetlen két út, és csak az egyik ad olyan címet, amit te felügyelsz.
• Azt akarod, hogy a világ akkor is elérhető legyen, amikor a géped ki van kapcsolva. Az asztali gépen futó szerver addig létezik, amíg az asztali gép ébren van. Ha az emberek különböző időpontokban játszanak, pontosan ez a probléma, és semmilyen portbeállítás nem oldja meg.
• Inkább nem adnád ki az otthoni címedet. Főleg, ha a szerver nyilvános lesz, vagy ha a belépők nem a te barátaid, hanem a gyerekedéi.
• Néhány játékosnál többen vagytok. Egy lakossági feltöltési sáv és egy közben másra is használt gép is kezd meglátszani, és ez lagként jelenik meg, ami játékhibának tűnik.

Ami megváltozik: a cím adatközponti cím lesz, nem a házadé, magától fennmarad, és a rá irányuló támadás nem viszi le a családodat az internetről. Egy menedzselt csomag ráadásul leveszi rólad ennek az oldalnak a robotmunka részeit — nincs továbbítás, nincs dynamic DNS, nincs tűzfalszabály. A HytHost szerverei NVMe tárolón futnak 99,9%-os rendelkezésre állási SLA-val, előttük Voxility DDoS-szűréssel, élő chates támogatással reggel 8-tól este 11-ig (chișinăui idő szerint). Ha már van világod a gépeden, az átköltöztetés egy mappa átmásolása, és megcsináljuk helyetted.

Ha még egyáltalán nem építetted meg a szervert, kezdd inkább azzal, hogyan csinálj Minecraft szervert — ez az oldal azt feltételezi, hogy már fut egy, és csak a kapcsolat hiányzik.