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.

RoleAddressWhere it belongs
Public transport endpoint203.0.113.40VPN client configuration, never the game
Game host on the VPN10.60.0.20Server address field, with the port
Player peer10.60.0.30Assigned 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.

Artigos relacionados