Minecraft over ein VPN: kva adresse skal i serverlista?

Å skrive VPN-endepunktet i serverlista til Minecraft kjennest logisk og feilar kvar gong, fordi den adressa avsluttar tunnelen i staden for å vere vert for spelet. Ein spelar som er kopla til same VPN har alt ein veg til verten for spelet, så oppføringa må namngje verten og porten spelet lyttar på. Få desse to rett, og resten av problemet er vanleg tenestetilgjenge, ei mykje kortare sjekkliste enn det først ser ut som.

To adresser, to oppgåver

Den eine adressa er offentleg infrastruktur: transportendepunktet som fraktar krypterte pakkar mellom peerar. Den andre er ei privat adresse som høyrer til maskina som køyrer den dedikerte serveren. Dei er ikkje utskiftbare, og å byte den eine mot den andre gjev ei avvist tilkopling eller ein tidsavbrot som ser ut som eit brannmurproblem.

Med standardporten skriv spelaren 10.60.0.20:25565 og ingenting anna. Java-server-nedlastingssida til Mojang oppgir 25565 som standard, og ein serveroperatør som har endra porten må ein tru på i staden for å tvile ut frå ein gammal rettleiar.

Gjer den adressa til ei ekte teneste

Ei nåbar adresse er naudsynt og ikkje tilstrekkeleg. Den dedikerte serveren må køyre, vere kompatibel med versjonen klienten til spelaren køyrer, og lytte på ei adresse tunnelen kan levere til. Ein prosess som berre er bunden til loopback, vert ikkje nåbar fordi nokon la til ei anna adresse på maskina.

Stadfest lyttaren før du rører ein brannmur:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Den første linja viser kva prosessen faktisk batt til, og den andre viser om ein peer kan fullføre ein TCP-handtrykk. Når bindinga er 127.0.0.1, endrar inga mengd VPN-konfigurasjon resultatet, og den eine detaljen forklarer eit overraskande tal på «VPN er øydelagt»-rapportar.

Peer-politikk, brannmur og returvegen

To løyve-spørsmål kviler oppå lyttaren. Peer-konfigurasjonen til VPN må tillate trafikk mellom dei to peerane, og brannmuren til verten for spelet må godta speleporten frå den peeren. Hald begge avgrensa til speletekesta og dei autoriserte peerane i staden for å slå av brannmuren til verten, noko som byter ein regel på to linjer mot eit mykje større problem. Smale reglar er også den einaste versjonen av dette som overlever ein tryggleiksrevisjon utan eit avsnitt med grunngjeving.

Hugs så kva ein vellukka ping beviser. Å nå VPN-gatewayen eller få svar frå verten for spelet viser berre at ICMP kryssa vegen. Ei speletilkopling krev at den spesifikke porten er open i begge retningar, og returvegen tel like mykje som den utgåande.

Når serveren står bak gatewayen

Dømet ovanfor har spelserveren som peer, noko som held adresseplanen enkel. Viss serveren i staden bur på eit LAN bak ein VPN-gateway, treng spelaren den rutbare private adressa til serveren, gatewayen må ha vidaresending konfigurert for det LAN-et, og LAN-verten treng ei rute tilbake mot den tunnelkopla klienten. Går returvegen tapt, døyr handtrykket halvvegs, noko som er den mest forvirrande av dei tre feila.

Ikkje kopier peer-adressa frå dømet til ei anna maskin for å etterlikne denne topologien. Adresser i eit døme skildrar rollar, og gjenbruk av éi adresse i to rollar skapar ei overlapping som ruting ikkje kan løyse.

Oppdaging, kontoar og kva du ikkje bør endre

Automatisk LAN-oppdaging er ei lettvintheit bygd på annonseringar. Eit ruta VPN treng ikkje å bere desse kringkastingane, så ei manglande oppføring i LAN-lista seier ingenting om den eksplisitte private adressa verkar. Skriv inn adressa, og døm deretter. Viss ho koplar til, er oppdagingsholet ei brukarvennlegheitsplage og ikkje ein feil, og det kan dokumenterast som slikt i staden for å granskast.

Hald også den normale kontosamkjenninga og opptakspolitikken til spelet intakt. Ei fungerande privat rute gjev ein veg, ikkje medlemskap, og inga omrokkering av adapterprioritet erstattar identifiseringa av destinasjonen klienten bør bruke.