Lista de jogos LAN vazia via OpenVPN? Verifique o caminho de descoberta

Fazer ping no endereço de túnel de outro jogador e ver o jogo hospedado dele são duas conquistas diferentes. A lista do lobby normalmente depende de uma troca de descoberta escrita para uma única rede local, enquanto a sessão de jogo é uma conexão comum a um endereço e uma porta. Tratar uma lista vazia como falha de roteamento leva você a uma bridge que talvez não precise, então separe as duas perguntas antes de mudar qualquer coisa.

Separe entrar numa sessão de encontrá-la

Uma entrada falha aponta para rotas, regras de firewall e um serviço escutando. Uma entrada bem-sucedida com lista vazia aponta para a descoberta, ou para o endereço que o anúncio carrega. Esses dois resultados levam a trabalhos completamente diferentes, e só é possível distingui-los tentando o primeiro de propósito.

Anote o resultado antes de tocar na configuração da VPN. É o teste mais barato de toda a investigação e elimina metade do espaço de projeto. Anote também o endereço usado, porque ele se torna o ponto de referência para cada teste posterior. Sem essa linha nas notas, a próxima comparação é um palpite.

Teste uma entrada direta antes de tocar no túnel

Se o jogo oferece uma opção de conexão direta, use o endereço de túnel do host e a porta documentada do jogo, e deixe intactos a autenticação do próprio jogo e as regras de firewall do host. Uma entrada bem-sucedida estreita o problema para a descoberta. Uma entrada falha ainda precisa da própria investigação, e nenhum relay a corrige.

Não presuma que a porta de descoberta e a porta da sessão sejam o mesmo número. Os jogos costumam anunciar em uma porta UDP e aceitar jogadores em outra, e um relay construído para a porta errada produz uma lista que continua vazia.

Verifique também qual adaptador o processo de hospedagem escolheu. Um processo ligado ao endereço da LAN doméstica anunciará esse endereço, e o jogador remoto não consegue rotear até ele mesmo quando o anúncio chega. A lista pode se preencher e a entrada pode falhar só por isso.

Entenda onde a difusão para

Um túnel TUN roteado transporta pacotes IP entre pares e não reproduz a difusão local na rede de cada par. O endereço de difusão limitada 255.255.255.255 fica dentro da interface que o emite, e uma difusão direcionada à sub-rede é um caso à parte, não uma licença geral para roteadores inundarem anúncios.

Isso é uma propriedade do projeto, não um defeito a ser remendado com uma opção. OpenVPN e sua opção client-to-client controla o tráfego entre pares dentro do túnel e não é um relay de descoberta, embora seja sugerida para esse fim em muitos tópicos. Um relay é um componente separado com a própria configuração e os próprios modos de falha. Supor que uma opção existente já cobre isso é a forma mais comum de esta investigação travar.

A descoberta por multicast tem o mesmo problema com outra classe de endereços, e precisa de roteamento multicast ou de um relay em vez de uma exceção de difusão.

Quando um relay é justificável, mantenha-o estreito

Se a descoberta automática é um requisito, identifique primeiro a troca real: difusão ou multicast, endereço de destino, porta UDP, a interface que a envia e o endereço dentro da resposta. Um relay adequado ao protocolo e limitado a esses cinco fatos é muito mais estreito do que estender um segmento Ethernet inteiro.

Encaminhar o pacote sem alterações ainda pode ser insuficiente. Se o payload diz ao receptor para se conectar a um endereço que ele não alcança, o relay entrega uma resposta inútil, por isso a interface do próprio jogo ou o ajuste de endereço anunciado deve ser testado antes que exista qualquer relay.

Limite o relay às interfaces e aos pares que precisam dele, e defina como as respostas encontram o solicitante. Repetir difusões não relacionadas expõe outros serviços locais e cria laços difíceis de depurar depois.

Bridge só quando o projeto exige Ethernet

Quadros Ethernet viajam dentro do TAP, então um túnel TAP pode pertencer a um domínio de difusão deliberadamente ligado por bridge. Apenas trocar dev tun por dev tap não constrói essa bridge, não torna a configuração do servidor compatível e não faz a aplicação escolher a nova interface. O guia de bridges do OpenVPN descreve o arranjo mais amplo, não uma cura para um lobby vazio.

A bridge também achata o plano de endereços, e por isso a decisão merece uma razão além da impaciência. Duas redes que estavam separadas tornam-se uma, e cada serviço de cada lado começa a ver as difusões do outro lado. Essa consequência pertence ao registro de mudanças antes que alguém a ative. Não há regra de que clientes de jogo devam ficar numa faixa 192.168; escolha um plano sem sobreposição e verifique as restrições do jogo específico em vez de renumerar o túnel porque um post de fórum fez isso.

No fim, mantenha os dois resultados separados: se dá para entrar no host, e se a resposta de descoberta anuncia um destino que o outro jogador realmente consegue usar. Corrigir o segundo sem confirmar o primeiro é como as pessoas acabam mantendo uma bridge para um problema que nunca foi sobre difusão.