Per què fallen les cerques de noms per un túnel OpenVPN encaminat

Un amfitrió respon al ping per adreça i falla totes les cerques per nom. El túnel està aixecat i la ruta existeix, o sigui que la conclusió natural és que la VPN està mal configurada. Una conclusió més útil és que la cerca mai no era encaminable: un túnel encaminat només transporta unicast IP, mentre que la consulta era una difusió que buscava un segment que no existeix a l'altre costat. Un cop el desajust de capes és visible, les solucions s'ordenen soles segons el cost.

Mite: el túnel està trencat perquè fallen els noms

El símptoma convenç perquè tot el que hi ha per sobre de la capa de noms funciona. Les adreces s'encaminen, la interfície està aixecada i el pare respon a un ping. El que va fallar és un mecanisme de descobriment que mai no havia tingut camí per un enllaç punt a punt, i això és una afirmació diferent d'un túnel trencat. Separar aquestes dues afirmacions és la major part del diagnòstic.

Tractar-ho com una avaria del túnel porta a editar el perfil sense cap efecte. Afegir opcions, canviar el xifratge o reinstal·lar el client deixa la difusió exactament on era.

Anomeneu el mecanisme que va fallar abans d'anomenar la solució. Una cerca que fa servir difusió necessita un segment, mentre que una cerca que fa servir un resolutor necessita una adreça a qui preguntar.

Què transporta TUN i què no

Un dispositiu TUN és una interfície IP, i això és el que el fa encaminable. OpenVPN dóna al client una adreça i un conjunt de rutes, i a partir d'aquí el client envia datagrames a un pare. Res en aquest model no crea un enllaç compartit on cada amfitrió sent cada trama.

El trànsit de descobriment no encaixa gens en aquest model. Les consultes de nom antigues de Windows, els anuncis SSDP i les peticions mDNS s'envien a tothom del segment en lloc d'una sola destinació. Un enllaç encaminat no té cap «tothom» a qui enviar. Cadascun d'aquests mecanismes pressuposa un mitjà compartit.

Per tant el túnel pot estar sa mentre el descobriment falla del tot. Aquesta frase és la que cal retenir quan algú informa que la VPN està caiguda.

El pont funciona eliminant la frontera

Un dispositiu TAP transporta trames, i un pont l'enganxa a un segment LAN real. Llavors el client té una adreça en aquell segment i sent el seu trànsit de difusió. Per això el pont sembla curar el problema dels noms. També fa que el client depengui d'aquell segment per a l'adreçament.

La cura és eliminar la frontera d'encaminament, no cap capacitat nova de noms dins del túnel. Tot el que el segment difon ara també travessa l'enllaç.

Per a un laboratori petit és un intercanvi just. Per a una plantilla distribuïda, poques vegades.

Empènyer DNS i WINS és la reparació més estreta

Doneu al client un lloc concret on preguntar. dhcp-option DNS i dhcp-option DOMAIN adrecen els noms interns a un servidor que coneix la zona, i un client Windows que encara depèn de NetBIOS pot rebre un servidor WINS de la mateixa manera. El túnel continua encaminat i el segment es queda on toca.

Dues condicions decideixen si això funciona. El servidor anomenat ha de respondre per la zona, i la consulta ha de ser permesa a través del túnel.

Proveu el resolutor des del client i no des de l'intèrpret del propi servidor. Un resolutor que funciona en local no diu res sobre el que transporta el túnel.

Esbrineu quina capa va fallar

Primer feu ping a l'adreça, després resoleu el nom i llegiu quin servidor ha respost. Una resposta negativa d'un servidor que no allotja la zona es veu diferent d'una consulta que no va sortir mai de la màquina. Un nom que es resol però refusa connexions és un tercer problema del tot.

El multicast és darrere la mateixa paret. Un grup com 224.0.0.251 no es reenvia per un túnel encaminat per defecte, i una ruta per al grup no n'hi ha prou sense un camí conscient de multicast o un reflector a la LAN.