Minecraft over en VPN: hvilken adresse skal i serverlisten?

Å skrive VPN-endepunktet i Minecrafts serverliste føles logisk og feiler hver gang, fordi den adressen avslutter tunnelen i stedet for å være vert for spillet. En spiller som er koblet til samme VPN har allerede en vei til spillverten, så oppføringen må navngi verten og porten spillet lytter på. Få disse to riktig, og resten av problemet er vanlig tjenestetilgjengelighet, en mye kortere sjekkliste enn det først ser ut som.

To adresser, to oppgaver

Den ene adressen er offentlig infrastruktur: transportendepunktet som frakter krypterte pakker mellom peerer. Den andre er en privat adresse som tilhører maskinen som kjører den dedikerte serveren. De er ikke utskiftbare, og å bytte den ene mot den andre gir en avvist tilkobling eller en tidsavbrudd som ser ut som et brannmurproblem.

Med standardporten skriver spilleren 10.60.0.20:25565 og ingenting annet. Mojangs Java-server-nedlastingsside oppgir 25565 som standard, og en serveroperatør som har endret porten, må man tro på i stedet for å tvile ut fra en gammel veiledning.

Gjør den adressen til en ekte tjeneste

En nåbar adresse er nødvendig og ikke tilstrekkelig. Den dedikerte serveren må kjøre, være kompatibel med versjonen spillerens klient kjører, og lytte på en adresse tunnelen kan levere til. En prosess som bare er bundet til loopback, blir ikke nåbar fordi noen la til en annen adresse på maskinen.

Bekreft lytteren før du rører en brannmur:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Den første linjen viser hva prosessen faktisk bandt til, og den andre viser om en peer kan fullføre en TCP-håndtrykk. Når bindingen er 127.0.0.1, endrer ingen mengde VPN-konfigurasjon resultatet, og den ene detaljen forklarer et overraskende antall «VPN er ødelagt»-rapporter.

Peer-policy, brannmur og returveien

To tillatelsesspørsmål hviler oppå lytteren. VPN-ets peer-konfigurasjon må tillate trafikk mellom de to peerene, og spillvertens brannmur må godta spillporten fra den peeren. Hold begge avgrenset til spilltjenesten og de autoriserte peerene i stedet for å slå av vertens brannmur, noe som bytter en regel på to linjer mot et mye større problem. Smale regler er også den eneste versjonen av dette som overlever en sikkerhetsrevisjon uten et avsnitt med begrunnelse.

Husk så hva en vellykket ping beviser. Å nå VPN-gatewayen eller få svar fra spillverten viser bare at ICMP krysset veien. En spilltilkobling krever at den spesifikke porten er åpen i begge retninger, og returveien betyr like mye som den utgående.

Når serveren står bak gatewayen

Eksempelet ovenfor har spillserveren som peer, noe som holder adresseplanen enkel. Hvis serveren i stedet bor på et LAN bak en VPN-gateway, trenger spilleren serverens rutbare private adresse, gatewayen må ha videreformidling konfigurert for det LAN-et, og LAN-verten trenger en rute tilbake mot den tunnelkoblede klienten. Går returveien tapt, dør håndtrykket halvveis, noe som er den mest forvirrende av de tre feilene.

Ikke kopier eksempelets peer-adresse til en annen maskin for å etterligne denne topologien. Adresser i et eksempel beskriver roller, og gjenbruk av én adresse i to roller skaper en overlapping som ruting ikke kan løse.

Oppdagelse, kontoer og hva du ikke bør endre

Automatisk LAN-oppdagelse er en bekvemmelighet bygget på annonseringer. Et rutet VPN trenger ikke å bære disse kringkastingene, så en manglende oppføring i LAN-listen sier ingenting om hvorvidt den eksplisitte private adressen fungerer. Skriv inn adressen, og døm deretter. Hvis den kobler til, er oppdagelseshullet en brukervennlighetsplage og ikke en feil, og det kan dokumenteres som sådan i stedet for å undersøkes.

Behold også spillets normale kontogodkjenning og opptakspolitikk intakt. En fungerende privat rute gir en vei, ikke medlemskap, og ingen omrokkering av adapterprioritet erstatter identifiseringen av destinasjonen klienten bør bruke.