Minecraft por VPN: que enderezo vai na lista de servidores?
O extremo da VPN constrúe o túnel; o xogo necesita o enderezo privado do host e o porto. Asigna roles a enderezos e despois revisa o escoitador, a ruta e as regras do host.
Escribir o extremo da VPN na lista de servidores de Minecraft parece lóxico e falla sempre, porque ese enderezo remata o túnel en lugar de aloxar o xogo. Un xogador conectado á mesma VPN xa ten un camiño cara ao host do xogo, así que a entrada debe nomear o host e o porto no que escoita o xogo. Acerta eses dous e o resto do problema é dispoñibilidade normal do servizo, unha lista de comprobación moito máis curta do que parece ao principio.
Dous enderezos, dúas tarefas
Un enderezo é infraestrutura pública: o extremo de transporte que leva paquetes cifrados entre pares. O outro é un enderezo privado da máquina que executa o servidor dedicado. Non son intercambiables, e substituír un polo outro produce unha conexión rexeitada ou un tempo de espera esgotado que parece un problema de firewall.
| 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 |
Co porto predeterminado, o xogador escribe 10.60.0.20:25565 e nada máis. A páxina de descarga do servidor Java de Mojang indica 25565 como porto predeterminado, e ao operador que cambiou o porto hai que crerlle en lugar de dubidar del por un tutorial antigo.
Converte ese enderezo nun servizo real
Un enderezo alcanzable é necesario e non suficiente. O servidor dedicado ten que estar en marcha, ten que ser compatible coa versión que executa o cliente do xogador e ten que escoitar nun enderezo ao que o túnel poida entregar. Un proceso ligado só a loopback non se volve alcanzable porque alguén engadise outro enderezo á máquina.
Confirma o escoitador antes de tocar un firewall:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565
A primeira liña mostra a que se ligou realmente o proceso, e a segunda mostra se un par pode completar o salto de mans TCP. Cando a ligazón é 127.0.0.1, ningunha cantidade de configuración de VPN cambia o resultado, e ese único detalle explica unha cantidade sorprendente de informes de «a VPN está rota».
Política de pares, firewall e ruta de volta
Dúas preguntas de permisos sentan por riba do escoitador. A configuración de pares da VPN ten que permitir tráfico entre os dous pares, e o firewall do host do xogo ten que aceptar o porto do xogo desde ese par. Mantén ambos acoutados ao servizo do xogo e aos pares autorizados en lugar de desactivar o firewall do host, que cambia unha regra de dúas liñas por un problema moito maior. As regras estreitas son ademais a única versión disto que supera unha revisión de seguridade sen un parágrafo de xustificación.
Despois lembra que demostra un ping correcto. Chegar á pasarela da VPN, ou recibir resposta do host do xogo, só demostra que ICMP cruzou o camiño. Unha conexión de xogo necesita o porto concreto aberto en ambas as direccións, e a ruta de volta importa tanto como a de ida.
Cando o servidor está detrás da pasarela
O exemplo anterior ten o servidor de xogo como par, o que mantén trivial o plan de enderezos. Se o servidor vive nunha LAN detrás dunha pasarela VPN, o xogador necesita o enderezo privado encamiñable do servidor, a pasarela necesita o reenvío configurado para esa LAN, e o host da LAN necesita unha ruta de volta cara ao cliente tunelizado. Se perdes a ruta de volta, o salto de mans morre a medio camiño, que é o fallo máis confuso dos tres.
Non copies o enderezo de par do exemplo noutra máquina para imitar esta topoloxía. Os enderezos dun exemplo describen roles, e reutilizar un en dous roles crea un solapamento que o encamiñamento non pode resolver.
Descubrimento, contas e que non cambiar
O descubrimento automático de LAN é unha comodidade construída sobre anuncios. Unha VPN encamiñada non ten por que transportar esas difusións, así que unha entrada ausente na lista de LAN non di nada sobre se o enderezo privado explícito funciona. Escribe o enderezo e logo xulga. Se conecta, o oco de descubrimento é unha molestia de usabilidade e non un fallo, e pode documentarse como tal en lugar de investigarse.
Mantén intactas tamén a autenticación normal da conta e a política de admisión do xogo. Unha ruta privada que funciona concede un camiño, non unha pertenza, e ningún reordenamento de prioridades de adaptador substitúe a identificación do destino que o cliente debería estar usando.