Por que as consultas de nomes falham num túnel OpenVPN encaminhado

Um host responde ao ping por endereço e falha em todas as consultas por nome. O túnel está activo e a rota existe, então a conclusão natural é que a VPN está mal configurada. Uma conclusão mais útil é que a consulta nunca foi encaminhável: um túnel encaminhado transporta unicast IP, enquanto a consulta era uma difusão à procura de um segmento que não existe do outro lado. Assim que o desencontro de camadas fica visível, as correções ordenam-se sozinhas por custo.

Mito: o túnel está quebrado porque os nomes falham

O sintoma convence porque tudo acima da camada de nomes funciona. Os endereços são encaminhados, a interface está activa e o par responde a um ping. O que falhou foi um mecanismo de descoberta que nunca teve caminho por um enlace ponto a ponto, e isso é uma afirmação diferente de um túnel quebrado. Separar essas duas afirmações é a maior parte do diagnóstico.

Tratar isso como uma falha do túnel leva a edições de perfil que não podem ajudar. Acrescentar opções, trocar a cifra ou reinstalar o cliente deixa a difusão exactamente onde estava.

Nomeie o mecanismo que falhou antes de nomear a correção. Uma consulta que usa difusão precisa de um segmento, enquanto uma consulta que usa um resolvedor precisa de um endereço a quem perguntar.

O que o TUN transporta e o que não transporta

Um dispositivo TUN é uma interface IP, e é isso que o torna encaminhável. OpenVPN entrega ao cliente um endereço e um conjunto de rotas, e a partir daí o cliente envia datagramas a um par. Nada nesse modelo cria um enlace partilhado onde cada host ouve cada trama.

O tráfego de descoberta não encaixa de todo nesse modelo. As consultas de nome antigas do Windows, os anúncios SSDP e os pedidos mDNS são enviados a todos num segmento em vez de a um único destino. Um enlace encaminhado não tem nenhum «todos» para onde enviar. Cada um desses mecanismos pressupõe um meio partilhado.

O túnel pode portanto estar saudável enquanto a descoberta falha por completo. É essa a frase a reter quando alguém relata que a VPN está em baixo.

A ponte funciona eliminando a fronteira

Um dispositivo TAP transporta tramas, e uma ponte liga-o a um segmento LAN real. O cliente passa então a ter um endereço nesse segmento e ouve o seu tráfego de difusão. É por isso que a ponte parece curar o problema dos nomes. Também torna o cliente dependente desse segmento para o endereçamento.

A cura é a remoção da fronteira de encaminhamento, não uma nova capacidade de nomes dentro do túnel. Tudo o que o segmento difunde atravessa agora também o enlace.

Para um laboratório pequeno é uma troca justa. Numa equipa dispersa raramente é.

Empurrar DNS e WINS é a reparação mais estreita

Dê ao cliente um sítio concreto onde perguntar. dhcp-option DNS e dhcp-option DOMAIN apontam os nomes internos para um servidor que conhece a zona, e um cliente Windows que ainda depende de NetBIOS pode receber um servidor WINS da mesma forma. O túnel continua encaminhado e o segmento fica onde pertence.

Duas condições decidem se isso funciona. O servidor indicado tem de responder pela zona, e a consulta tem de ser permitida através do túnel.

Teste o resolvedor a partir do cliente e não a partir da própria shell do servidor. Um resolvedor que funciona localmente não diz nada sobre o que o túnel transporta.

Descubra que camada falhou

Faça ping ao endereço primeiro, depois resolva o nome e leia que servidor respondeu. Uma resposta negativa de um servidor que não aloja a zona parece diferente de uma consulta que nunca saiu da máquina. Um nome que resolve mas recusa ligações é um terceiro problema completamente diferente.

O multicast está atrás da mesma parede. Um grupo como 224.0.0.251 não é reencaminhado por um túnel encaminhado por omissão, e uma rota para o grupo não chega sem um caminho consciente de multicast ou um reflector na LAN.