Psát koncový bod VPN do seznamu serverů Minecraftu vypadá logicky a pokaždé selže, protože tato adresa tunel ukončuje, místo aby hostovala hru. Hráč připojený ke stejné VPN už má cestu k hostiteli hry, takže záznam musí uvést hostitele a port, na kterém hra naslouchá. Zvládněte tyto dvě věci a zbytek problému je běžná dostupnost služby, což je mnohem kratší kontrolní seznam, než se na první pohled zdá.

Dvě adresy, dva úkoly

Jedna adresa je veřejná infrastruktura: transportní koncový bod, který přenáší šifrované pakety mezi peery. Druhá je privátní adresa stroje, který provozuje dedikovaný server. Nejsou zaměnitelné a záměna jedné za druhou vede k odmítnutému spojení nebo vypršení časového limitu, které vypadá jako problém firewallu.

RoleAddressWhere it belongs
Public transport endpoint203.0.113.40VPN client configuration, never the game
Game host on the VPN10.60.0.20Server address field, with the port
Player peer10.60.0.30Assigned by the tunnel, nothing to type

S výchozím portem hráč zadá 10.60.0.20:25565 a nic jiného. Stránka ke stažení Java serveru od Mojangu uvádí 25565 jako výchozí port a operátorovi, který port změnil, je třeba věřit, místo aby se o něm pochybovalo podle starého návodu.

Udělejte z té adresy skutečnou službu

Dostupná adresa je nutná, ale ne dostačující. Dedikovaný server musí běžet, musí být kompatibilní s verzí, kterou spouští hráčův klient, a musí naslouchat na adrese, kam tunel dokáže doručit. Proces vázaný jen na loopback se nestane dostupným proto, že někdo stroji přidal další adresu.

Ověřte posluchač, než se dotknete firewallu:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

První řádek ukazuje, k čemu se proces skutečně připojil, a druhý, zda peer dokáže dokončit TCP handshake. Když je vazba na 127.0.0.1, žádné množství konfigurace VPN výsledek nezmění, a tento jediný detail vysvětluje překvapivé množství hlášení „VPN je rozbitá“.

Politika peerů, firewall a zpětná cesta

Nad posluchačem stojí dvě otázky o oprávněních. Konfigurace peerů VPN musí povolit provoz mezi oběma peery a firewall hostitele hry musí přijmout port hry od tohoto peera. Držte obojí omezené na službu hry a oprávněné peery, místo abyste vypínali firewall hostitele, což vymění dvouřádkové pravidlo za mnohem větší problém. Úzká pravidla jsou také jediná verze tohoto, která projde bezpečnostní revizí bez odstavce odůvodnění.

Pak si připomeňte, co úspěšný ping dokazuje. Dosažení brány VPN nebo odpověď od hostitele hry dokazuje jen to, že ICMP prošel cestou. Herní spojení potřebuje konkrétní port otevřený v obou směrech a zpětná cesta je stejně důležitá jako odchozí.

Když server stojí za bránou

Výše uvedený příklad má herní server jako peer, což plán adres udržuje jednoduchý. Pokud server místo toho žije v LAN za bránou VPN, hráč potřebuje směrovatelnou privátní adresu serveru, brána potřebuje nakonfigurované předávání pro tuto LAN a hostitel v LAN potřebuje trasu zpět k tunelovanému klientovi. Vynechejte zpětnou cestu a handshake zemře v polovině, což je nejmateroucnější ze tří poruch.

Nekopírujte ukázkovou adresu peera na jiný stroj, abyste tuto topologii napodobili. Adresy v příkladu popisují role a opětovné použití jedné adresy ve dvou rolích vytváří překryv, který směrování nedokáže vyřešit.

Zjišťování, účty a co neměnit

Automatické zjišťování LAN je pohodlí postavené na oznámeních. Směrovaná VPN nemusí tyto broadcasty přenášet, takže chybějící záznam v seznamu LAN nic neříká o tom, zda explicitní privátní adresa funguje. Zadejte adresu a pak posuďte. Pokud se připojí, mezera ve zjišťování je obtíž s použitelností, nikoli porucha, a lze ji takto zdokumentovat, místo aby se vyšetřovala.

Zachovejte také normální autentizaci účtu a politiku přijetí hry. Fungující privátní trasa dává cestu, ne členství, a žádné přehazování priorit adaptérů nenahradí určení cíle, který má klient používat.

Související články