Minecraft över ett VPN: vilken adress hör hemma i serverlistan?

Att skriva VPN-ändpunkten i Minecrafts serverlista känns logiskt och misslyckas varje gång, eftersom den adressen avslutar tunneln i stället för att vara värd för spelet. En spelare som är ansluten till samma VPN har redan en väg till spelets värd, så posten måste ange värden och den port som spelet lyssnar på. Få de två rätt och resten av problemet är vanlig tjänstetillgänglighet, en mycket kortare checklista än det först verkar.

Två adresser, två uppgifter

En adress är offentlig infrastruktur: transportändpunkten som bär krypterade paket mellan peers. Den andra är en privat adress som tillhör maskinen som kör den dedikerade servern. De är inte utbytbara, och att byta den ena mot den andra ger en avvisad anslutning eller en timeout som ser ut som ett brandväggsproblem.

Med standardporten skriver spelaren 10.60.0.20:25565 och ingenting annat. Mojangs nedladdningssida för Java-servern anger 25565 som standard, och en serveroperatör som har ändrat porten måste man tro på i stället för att ifrågasätta utifrån en gammal guide.

Gör den adressen till en riktig tjänst

En nåbar adress är nödvändig och inte tillräcklig. Den dedikerade servern måste köra, vara kompatibel med den version som spelarens klient kör och lyssna på en adress som tunneln kan leverera till. En process som bara är bunden till loopback blir inte nåbar för att någon lade till en annan adress på maskinen.

Bekräfta lyssnaren innan du rör en brandvägg:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Den första raden visar vad processen faktiskt bands till, och den andra visar om en peer kan slutföra ett TCP-handskakning. När bindningen är 127.0.0.1 ändrar ingen mängd VPN-konfiguration resultatet, och just den detaljen förklarar ett överraskande antal rapporter om att «VPN:t är trasigt».

Peer-policy, brandvägg och returvägen

Två tillståndsfrågor sitter ovanpå lyssnaren. VPN:ets peer-konfiguration måste tillåta trafik mellan de två peerarna, och spelvärdens brandvägg måste acceptera spelporten från den peeren. Håll båda begränsade till speltjänsten och de auktoriserade peerarna i stället för att stänga av värdens brandvägg, vilket byter en regel på två rader mot ett mycket större problem. Smala regler är också den enda versionen av detta som klarar en säkerhetsgranskning utan ett stycke motivering.

Kom sedan ihåg vad en lyckad ping bevisar. Att nå VPN-gatewayen eller få svar från spelvärden visar bara att ICMP korsade vägen. En spelanslutning kräver att den specifika porten är öppen i båda riktningarna, och returvägen är lika viktig som den utgående.

När servern står bakom gatewayen

Exemplet ovan har spelservern som peer, vilket håller adressplanen enkel. Om servern i stället ligger på ett LAN bakom en VPN-gateway behöver spelaren serverns routbara privata adress, gatewayen måste ha vidarebefordran konfigurerad för det LAN:et, och värden på LAN:et behöver en rutt tillbaka mot den tunnlade klienten. Missar du returvägen dör handskakningen halvvägs, vilket är det mest förvirrande av de tre felen.

Kopiera inte exemplets peer-adress till en annan maskin för att efterlikna den här topologin. Adresser i ett exempel beskriver roller, och att återanvända en adress i två roller skapar en överlappning som routning inte kan lösa.

Upptäckt, konton och vad du inte ska ändra

Automatisk LAN-upptäckt är en bekvämlighet byggd på annonseringar. Ett routat VPN behöver inte bära de utsändningarna, så en saknad post i LAN-listan säger ingenting om huruvida den uttryckliga privata adressen fungerar. Skriv in adressen och bedöm sedan. Om den ansluter är upptäcktsgapet en användbarhetsolägenhet och inte ett fel, och det kan dokumenteras som sådant i stället för att utredas.

Behåll också spelets normala kontoauth och tillträdespolicy intakta. En fungerande privat rutt ger en väg, inte ett medlemskap, och ingen omflyttning av adapterprioriteter ersätter identifieringen av den destination som klienten borde använda.