Lista de xogos LAN baleira con OpenVPN? Revise a ruta de descuberta

Facer ping ao enderezo de túnel doutro xogador e ver o seu xogo aloxado son dous logros distintos. A lista do lobby adoita depender dun intercambio de descuberta escrito para unha única rede local, mentres que a sesión de xogo é unha conexión normal a un enderezo e un porto. Tratar unha lista baleira como un fallo de encamiñamento lévao cara a unha ponte que quizais non necesite, así que separe as dúas preguntas antes de cambiar nada.

Separe unirse a unha sesión de atopala

Unha unión fallida apunta a rutas, regras de cortafuegos e un servizo que escoita. Unha unión correcta cunha lista baleira apunta á descuberta ou ao enderezo que leva o anuncio. Eses dous resultados levan a un traballo completamente distinto, e só pode distinguilos probando o primeiro a propósito.

Anote o resultado antes de tocar a configuración da VPN. É a proba máis barata de toda a investigación e elimina a metade do espazo de deseño. Anote tamén o enderezo que usou, porque se converte no punto de referencia para cada proba posterior. Sen esa liña nas notas, a seguinte comparación é unha conxectura.

Probe unha unión directa antes de tocar o túnel

Se o xogo ofrece unha opción de conexión directa, use o enderezo de túnel do anfitrión e o porto documentado do xogo, e deixe intactas a autenticación propia do xogo e as regras de cortafuegos do anfitrión. Unha unión correcta reduce o problema á descuberta. Unha unión fallida segue necesitando a súa propia investigación, e ningún relé a arranxará.

Non supoña que o porto de descuberta e o porto de sesión son o mesmo número. Os xogos adoitan anunciarse nun porto UDP e aceptar xogadores noutro, e un relé construído para o equivocado produce unha lista que segue baleira.

Comprobe tamén que adaptador escolleu o proceso de aloxamento. Un proceso ligado ao enderezo da LAN doméstica anunciará ese enderezo, e o xogador remoto non pode encamiñar cara a el aínda que chegue o anuncio. A lista pode encherse e a unión pode fallar só por ese motivo.

Entenda onde se detén a difusión

Un túnel TUN encamiñado transporta paquetes IP entre pares e non reproduce a difusión local na rede de cada par. O enderezo de difusión limitada 255.255.255.255 queda dentro da interface que o emite, e unha difusión dirixida á subrede é un caso aparte, non unha licenza xeral para que os routers inundan anuncios.

Iso é unha propiedade do deseño, non un defecto que se parche con unha opción. OpenVPN e a súa opción client-to-client goberna o tráfico entre pares dentro do túnel e non é un relé de descuberta, aínda que se propón para ese fin en moitos fíos. Un relé é un compoñente aparte coa súa propia configuración e os seus propios modos de fallo. Supoñer que unha opción existente xa o cobre é a forma máis habitual de que esta investigación se atasca.

A descuberta por multicast ten o mesmo problema cunha clase de enderezos distinta, e necesita encamiñamento multicast ou un relé en lugar dunha excepción de difusión.

Cando un relé estea xustificado, mantéñao estreito

Se a descuberta automática é un requisito, identifique primeiro o intercambio real: difusión ou multicast, enderezo de destino, porto UDP, a interface que o envía e o enderezo dentro da resposta. Un relé axeitado ao protocolo e limitado a eses cinco feitos é moito máis estreito que estender un segmento Ethernet enteiro.

Reenviar o paquete sen cambios pode seguir sendo insuficiente. Se a carga útil lle di ao receptor que se conecte a un enderezo que non pode alcanzar, o relé entrega unha resposta inútil, por iso convén probar a interface propia do xogo ou o axuste de enderezo anunciado antes de que exista ningún relé.

Limite o relé ás interfaces e aos pares que o necesitan, e defina como atopan as respostas o solicitante. Repetir difusións non relacionadas expón outros servizos locais e crea bucles que despois son dolorosos de depurar.

Ponte só cando o deseño necesite Ethernet

As tramas Ethernet viaxan dentro de TAP, así que un túnel TAP pode pertencer a un dominio de difusión deliberadamente pontado. Simplemente cambiar dev tun por dev tap non constrúe esa ponte, non fai compatible a configuración do servidor e non fai que a aplicación escolla a nova interface. A guía de pontes de OpenVPN describe o arranxo máis amplo, non unha cura para un lobby baleiro.

A ponte tamén achanda o plan de enderezos, por iso a decisión merece unha razón máis aló da impaciencia. Dúas redes que estaban separadas convértense nunha, e cada servizo de cada lado comeza a ver as difusións do outro lado. Esa consecuencia pertence ao rexistro de cambios antes de que ninguén a active. Non hai ningunha regra que obrigue os clientes de xogo a estar nun rango 192.168; escolla un plan sen solapamento e comprobe as restricións do xogo concreto en lugar de renumerar o túnel porque o fixo unha publicación de foro.

Ao final manteña os dous resultados separados: se se pode unir ao anfitrión e se a resposta de descuberta anuncia un destino que o outro xogador realmente pode usar. Arranxar o segundo sen confirmar o primeiro é como a xente acaba mantendo unha ponte para un problema que nunca tivo que ver coa difusión.