Por que fallan as buscas de nomes nun túnel OpenVPN encamiñado

Un host responde ao ping por enderezo e falla toda busca por nome. O túnel está levantado e a ruta existe, así que a conclusión natural é que a VPN está mal configurada. Unha conclusión máis útil é que a busca nunca foi encamiñable: un túnel encamiñado transporta unicast IP, mentres que a consulta era unha difusión que buscaba un segmento que non existe no outro lado. En canto o desaxuste de capas se fai visible, as solucións ordénanse soas por custo.

Mito: o túnel está roto porque fallan os nomes

O síntoma convence porque todo o que está por riba da capa de nomes funciona. Os enderezos encamíñanse, a interface está levantada e o par responde a un ping. O que fallou é un mecanismo de descuberta que nunca tivo camiño por unha ligazón punto a punto, e iso é unha afirmación distinta dun túnel roto. Separar esas dúas afirmacións é a maior parte do diagnóstico.

Tratalo como unha avaría do túnel leva a editar o perfil sen efecto algún. Engadir opcións, cambiar o cifrado ou reinstalar o cliente deixa a difusión exactamente onde estaba.

Nomea o mecanismo que fallou antes de nomear a solución. Unha busca que usa difusión necesita un segmento, mentres que unha busca que usa un resolutor necesita un enderezo ao que preguntar.

Que transporta TUN e que non

Un dispositivo TUN é unha interface IP, e iso é o que o fai encamiñable. OpenVPN entrega ao cliente un enderezo e un conxunto de rutas, e desde aí o cliente envía datagramas a un par. Nada nese modelo crea unha ligazón compartida onde cada host oe cada trama.

O tráfico de descuberta non encaixa en absoluto nese modelo. As consultas de nome antigas de Windows, os anuncios SSDP e as peticións mDNS envíanse a todos nun segmento en lugar de a un único destino. Unha ligazón encamiñada non ten ningún «todos» ao que enviar. Cada un deses mecanismos presupón un medio compartido.

O túnel pode polo tanto estar san mentres a descuberta falla por completo. Esa frase é a que hai que reter cando alguén informa de que a VPN está caída.

A ponte funciona eliminando a fronteira

Un dispositivo TAP transporta tramas, e unha ponte engancha nel a un segmento LAN real. O cliente ten entón un enderezo nese segmento e oe o seu tráfico de difusión. Por iso a ponte parece curar o problema dos nomes. Tamén fai que o cliente dependa dese segmento para o enderezo.

A cura é eliminar a fronteira de encamiñamento, non unha capacidade nova de nomes dentro do túnel. Todo o que o segmento difunde agora cruza tamén a ligazón.

Para un laboratorio pequeno é un intercambio xusto. Nunha plantilla distribuída raramente o é.

Empuxar DNS e WINS é a reparación máis estreita

Dálle ao cliente un sitio concreto ao que preguntar. dhcp-option DNS e dhcp-option DOMAIN apuntan os nomes internos a un servidor que coñece a zona, e un cliente Windows que aínda depende de NetBIOS pode recibir un servidor WINS do mesmo xeito. O túnel segue encamiñado e o segmento queda onde corresponde.

Dúas condicións deciden se iso funciona. O servidor nomeado debe responder pola zona, e a consulta debe estar permitida a través do túnel.

Proba o resolutor desde o cliente e non desde o propio shell do servidor. Un resolutor que funciona en local non di nada sobre o que transporta o túnel.

Averigua que capa fallou

Fai ping ao enderezo primeiro, despois resolve o nome e le que servidor respondeu. Unha resposta negativa dun servidor que non aloxa a zona vese distinta dunha consulta que nunca saíu da máquina. Un nome que resolve pero rexeita conexións é un terceiro problema por completo.

O multicast está detrás do mesmo muro. Un grupo como 224.0.0.251 non se reenvía por un túnel encamiñado de forma predeterminada, e unha ruta para o grupo non abonda sen un camiño consciente de multicast ou un reflector na LAN.