Minecraft over en VPN: hvilken adresse skal i serverlisten?

At skrive VPN-endepunktet i Minecrafts serverliste føles logisk og fejler hver gang, fordi den adresse afslutter tunnelen i stedet for at være vært for spillet. En spiller, der er forbundet til samme VPN, har allerede en vej til spilværten, så posten skal angive værten og den port, spillet lytter på. Få de to ting rigtigt, og resten af problemet er almindelig tjenestetilgængelighed, hvilket er en meget kortere tjekliste, end det først ser ud.

To adresser, to opgaver

Den ene adresse er offentlig infrastruktur: transportendepunktet, der bærer krypterede pakker mellem peers. Den anden er en privat adresse, der tilhører maskinen, som kører den dedikerede server. De kan ikke udskiftes, og at sætte den ene i stedet for den anden giver en afvist forbindelse eller en timeout, der ligner et firewallproblem.

Med standardporten skriver spilleren 10.60.0.20:25565 og intet andet. Mojangs Java-server-downloadside angiver 25565 som standard, og en serveroperatør, der har ændret porten, skal man tro på i stedet for at tvivle ud fra en gammel vejledning.

Gør den adresse til en rigtig tjeneste

En tilgængelig adresse er nødvendig og ikke tilstrækkelig. Den dedikerede server skal køre, være kompatibel med den version, spillerens klient kører, og lytte på en adresse, som tunnelen kan levere til. En proces, der kun er bundet til loopback, bliver ikke tilgængelig, fordi nogen har tilføjet en anden adresse til maskinen.

Bekræft listeneren, før du rører en firewall:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Den første linje viser, hvad processen faktisk bandt til, og den anden viser, om en peer kan gennemføre et TCP-håndtryk. Når bindingen er 127.0.0.1, ændrer ingen mængde VPN-konfiguration resultatet, og den ene detalje forklarer et overraskende antal »VPN er i stykker«-rapporter.

Peer-politik, firewall og returvejen

To tilladelsesspørgsmål hviler oven på listeneren. VPN’ets peer-konfiguration skal tillade trafik mellem de to peers, og spilværtens firewall skal acceptere spilporten fra den peer. Hold begge afgrænset til spiltjenesten og de autoriserede peers i stedet for at slå værtens firewall fra, hvilket bytter en regel på to linjer for et meget større problem. Snævre regler er også den eneste version af dette, der overlever en sikkerhedsrevision uden et afsnit med begrundelse.

Husk så, hvad et vellykket ping beviser. At nå VPN-gatewayen eller få svar fra spilværten viser kun, at ICMP krydsede vejen. En spilforbindelse kræver, at den specifikke port er åben i begge retninger, og returvejen betyder lige så meget som den udgående.

Når serveren står bag gatewayen

Eksemplet ovenfor har spilserveren som peer, hvilket holder adresseplanen enkel. Hvis serveren i stedet bor på et LAN bag en VPN-gateway, har spilleren brug for serverens rutbare private adresse, gatewayen skal have videresendelse konfigureret til det LAN, og LAN-værten har brug for en rute tilbage mod den tunnellerede klient. Gå glip af returvejen, og håndtrykket dør halvvejs, hvilket er den mest forvirrende af de tre fejl.

Kopier ikke eksemplets peer-adresse til en anden maskine for at efterligne denne topologi. Adresser i et eksempel beskriver roller, og genbrug af en adresse på tværs af to roller skaber et overlap, som routing ikke kan løse.

Opdagelse, konti og hvad du ikke skal ændre

Automatisk LAN-opdagelse er en bekvemmelighed bygget på annonceringer. Et routet VPN behøver ikke at bære disse broadcasts, så en manglende post i LAN-listen siger intet om, hvorvidt den eksplicitte private adresse virker. Skriv adressen, og døm derefter. Hvis den forbinder, er opdagelseshullet en brugervenlighedsgener, ikke en fejl, og det kan dokumenteres som sådant i stedet for at blive undersøgt.

Behold også spillets normale kontogodkendelse og adgangspolitik intakt. En fungerende privat rute giver en vej, ikke medlemskab, og ingen omrokering af adapterprioritet erstatter identificeringen af den destination, klienten bør bruge.