Minecraft via 'n VPN: watter adres hoort in die bedienerlys?
Die VPN-eindpunt bou die tonnel; die speletjie het die gasheer se private adres en poort nodig. Karteer rolle na adresse en kontroleer dan luisteraar, roete en gasheerreëls.
Om die VPN-eindpunt in Minecraft se bedienerlys in te tik voel logies en misluk elke keer, want daardie adres beëindig die tonnel eerder as om die speletjie te huisves. 'n Speler wat by dieselfde VPN aangesluit het, het reeds 'n pad na die speletjie-gasheer, so die inskrywing moet die gasheer en die poort noem waarop die speletjie luister. Kry daardie twee reg en die res van die probleem is gewone diensbereikbaarheid, wat 'n baie korter kontrolelys is as wat dit aanvanklik lyk.
Twee adresse, twee take
Een adres is openbare infrastruktuur: die vervoereindpunt wat geënkripteerde pakkette tussen eweknieë dra. Die ander is 'n private adres wat aan die masjien behoort wat die toegewyde bediener laat loop. Hulle is nie uitruilbaar nie, en om een vir die ander te vervang lewer 'n verbinding geweier of 'n tydverstryking wat soos 'n vuurmuurprobleem lyk.
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
Met die standaardpoort tik die speler 10.60.0.20:25565 en niks anders nie. Mojang se Java-bediener-aflaaisbladsy noem 25565 as die standaard, en 'n bedieneroperateur wat die poort verander het, moet geglo word eerder as om uit 'n ou handleiding te raai.
Maak daardie adres 'n werklike diens
'n Bereikbare adres is nodig en nie voldoende nie. Die toegewyde bediener moet loop, moet versoenbaar wees met die weergawe wat die speler se kliënt gebruik, en moet luister op 'n adres waarheen die tonnel kan aflewer. 'n Proses wat net aan loopback gebind is, word nie bereikbaar omdat iemand nog 'n adres by die masjien gevoeg het nie.
Bevestig die luisteraar voordat jy aan 'n vuurmuur raak:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565Die eerste reël wys waaraan die proses werklik gebind het, en die tweede wys of 'n eweknie 'n TCP-handdruk kan voltooi. Wanneer die binding 127.0.0.1 is, verander geen hoeveelheid VPN-konfigurasie die uitkoms nie, en daardie enkele detail verduidelik 'n verrassende aantal “die VPN is stukkend”-verslae.
Ewekniebeleid, vuurmuur en die antwoordpad
Twee toestemmingsvrae sit bo-op die luisteraar. Die VPN se ewekniekonfigurasie moet verkeer tussen die twee eweknieë toelaat, en die vuurmuur van die speletjie-gasheer moet die speletjiepoort van daardie eweknie aanvaar. Hou beide beperk tot die speletjiediens en die gemagtigde eweknieë in plaas daarvan om die gasheer se vuurmuur af te skakel, wat 'n reël van twee lyne vir 'n veel groter probleem verruil. Smal reëls is ook die enigste weergawe hiervan wat 'n sekuriteitsoudit oorleef sonder 'n paragraaf regverdiging.
Onthou dan wat 'n suksesvolle ping bewys. Om die VPN-gateway te bereik, of 'n antwoord van die speletjie-gasheer te kry, wys net dat ICMP die pad gekruis het. 'n Speletjieverbinding benodig die spesifieke poort oop in beide rigtings, en die antwoordpad maak net soveel saak soos die uitgaande een.
Wanneer die bediener agter die gateway sit
Die voorbeeld hierbo het die speletjie-bediener as 'n eweknie, wat die adresplan eenvoudig hou. As die bediener eerder op 'n LAN agter 'n VPN-gateway woon, het die speler die bediener se roeteerbare private adres nodig, moet die gateway vir daardie LAN opgestel word om te stuur, en die LAN-gasheer het 'n roete terug na die tonnel-kliënt nodig. Mis die terugpad en die handdruk sterf halfpad, wat die mees verwarrende mislukking van die drie is.
Moenie die voorbeeld se eweknieadres op 'n ander masjien kopieer om hierdie topologie na te boots nie. Adresse in 'n voorbeeld beskryf rolle, en om een oor twee rolle te hergebruik skep 'n oorvleueling wat roetering nie kan oplos nie.
Ontdekking, rekeninge en wat om nie te verander nie
Outomatiese LAN-ontdekking is 'n gerief wat op aankondigings gebou is. 'n Roeterende VPN hoef nie daardie uitsendings te dra nie, so 'n ontbrekende inskrywing in die LAN-lys sê niks oor of die eksplisiete private adres werk nie. Tik die adres en oordeel dan. As dit konnekteer, is die ontdekkingsgaping 'n bruikbaarheidslas eerder as 'n fout, en dit kan as sodanig gedokumenteer word in plaas daarvan om ondersoek te word.
Hou ook die speletjie se normale rekeningverifikasie en toelatingsbeleid ongeskonde. 'n Werkende private roete verleen 'n pad, nie lidmaatskap nie, en geen hoeveelheid skommeling met adapterprioriteit vervang die identifisering van die bestemming wat die kliënt behoort te gebruik nie.