Minecraft VPN-en át: melyik cím kerül a kiszolgálólistára?

A VPN végpontjának beírása a Minecraft kiszolgálólistájára logikusnak tűnik és minden alkalommal meghiúsul, mert az a cím a csatornát fejezi be, nem a játékot szolgálja ki. Az ugyanahhoz a VPN-hez csatlakozott játékosnak már van útvonala a játék gazdagépéhez, ezért a bejegyzésnek meg kell neveznie a gazdagépet és azt a portot, amelyen a játék figyel. Ha ezt a kettőt rendben teszi, a probléma többi része közönséges szolgáltatáselérhetőség, ami sokkal rövidebb ellenőrzőlista, mint elsőre látszik.

Két cím, két feladat

Az egyik cím nyilvános infrastruktúra: az a szállítási végpont, amely a titkosított csomagokat a partnerek között továbbítja. A másik a dedikált kiszolgálót futtató gép privát címe. Nem felcserélhetők, és az egyik helyettesítése a másikkal elutasított kapcsolatot vagy időtúllépést eredményez, amely tűzfalproblémának látszik.

Az alapértelmezett porttal a játékos 10.60.0.20:25565 ír be, és semmi mást. A Mojang Java kiszolgáló letöltési oldala a 25565-öt nevezi meg alapértelmezettként, és hinni kell a kiszolgáló-üzemeltetőnek, aki megváltoztatta a portot, ahelyett hogy egy régi útmutató alapján kételkednénk benne.

Tegye valódi szolgáltatássá azt a címet

Az elérhető cím szükséges és nem elégséges. A dedikált kiszolgálónak futnia kell, kompatibilisnek kell lennie a játékos kliense által futtatott verzióval, és olyan címen kell figyelnie, ahová a csatorna szállítani tud. A csak loopbackhez kötött folyamat nem válik elérhetővé attól, hogy valaki még egy címet adott a géphez.

Erősítse meg a figyelőt, mielőtt tűzfalhoz nyúl:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Az első sor megmutatja, mihez kötődött a folyamat valójában, a második pedig azt, hogy egy partner be tudja-e fejezni a TCP kézfogást. Amikor a kötés 127.0.0.1, semmilyen mennyiségű VPN-konfiguráció nem változtat az eredményen, és ez az egyetlen részlet meglepő számú „a VPN elromlott” jelentést magyaráz meg.

Partneri szabályok, tűzfal és a visszaút

Két engedélykérdés ül a figyelő fölött. A VPN partnerkonfigurációjának engedélyeznie kell a forgalmat a két partner között, és a játék gazdagépének tűzfalának el kell fogadnia a játék portját ettől a partnertől. Tartsa mindkettőt a játékszolgáltatásra és a jogosult partnerekre szűkítve, ahelyett hogy kikapcsolná a gazdagép tűzfalát, ami egy kétsoros szabályt sokkal nagyobb problémára cserél. A szűk szabályok az egyetlen változata ennek, amely egy bekezdésnyi indoklás nélkül átmegy egy biztonsági felülvizsgálaton.

Aztán emlékezzen, mit bizonyít egy sikeres ping. A VPN átjáró elérése vagy a játék gazdagépétől kapott válasz csak azt mutatja, hogy az ICMP átkelt az útvonalon. A játékkapcsolathoz a konkrét portnak mindkét irányban nyitva kell lennie, és a visszaút ugyanolyan fontos, mint a kifelé vezető.

Amikor a kiszolgáló az átjáró mögött van

A fenti példában a játék kiszolgálója partner, ami egyszerűen tartja a címtervet. Ha a kiszolgáló ehelyett egy VPN átjáró mögötti LAN-on él, a játékosnak a kiszolgáló útvonalazható privát címére van szüksége, az átjárónak továbbítás kell beállítania ahhoz a LAN-hoz, és a LAN gazdagépének visszaút kell az alagúton lévő kliens felé. Ha kimarad a visszaút, a kézfogás félúton meghal, ami a három hiba közül a legzavaróbb.

Ne másolja a példa partneri címét egy másik gépre ennek a topológiának az utánzásához. A példában szereplő címek szerepeket írnak le, és egy cím két szerepben való újrafelhasználása olyan átfedést hoz létre, amelyet az útvonalválasztás nem tud feloldani.

Felderítés, fiókok és mit ne változtassunk

Az automatikus LAN-felderítés hirdetésekre épülő kényelem. Az útvonalazott VPN-nek nem kell továbbítania azokat a sugárzásokat, ezért a LAN-listából hiányzó bejegyzés semmit sem mond arról, hogy a kifejezett privát cím működik-e. Írja be a címet, aztán ítéljen. Ha csatlakozik, a felderítési hézag használhatósági kellemetlenség, nem hiba, és ekként dokumentálható a vizsgálat helyett.

Tartsa érintetlenül a játék szokásos fiókazonosítását és belépési politikáját is. Egy működő privát útvonal utat ad, nem tagságot, és az adapterprioritások átrendezése nem helyettesíti annak a célnak az azonosítását, amelyet a kliensnek használnia kellene.