Perché le risoluzioni dei nomi falliscono su un tunnel OpenVPN instradato

Un host risponde al ping per indirizzo e fallisce ogni ricerca per nome. Il tunnel è attivo e la rotta esiste, quindi la conclusione naturale è che la VPN sia mal configurata. Una conclusione più utile è che la ricerca non è mai stata instradabile: un tunnel instradato trasporta unicast IP, mentre la query era un broadcast che cercava un segmento che non esiste dall'altra parte. Una volta visibile il disallineamento di livelli, le correzioni si ordinano da sole per costo.

Mito: il tunnel è rotto perché i nomi falliscono

Il sintomo convince perché tutto ciò che sta sopra il livello dei nomi funziona. Gli indirizzi vengono instradati, l'interfaccia è attiva e il peer risponde a un ping. Ciò che è fallito è un meccanismo di scoperta che non ha mai avuto un percorso su un collegamento punto a punto, e questa è un'affermazione diversa da un tunnel rotto. Separare queste due affermazioni è la maggior parte della diagnosi.

Trattarlo come un guasto del tunnel porta a modifiche del profilo che non possono aiutare. Aggiungere opzioni, cambiare la cifratura o reinstallare il client lascia il broadcast esattamente dov'era.

Nomina il meccanismo che è fallito prima di nominare la correzione. Una ricerca che usa il broadcast ha bisogno di un segmento, mentre una ricerca che usa un resolver ha bisogno di un indirizzo a cui chiedere.

Cosa trasporta TUN e cosa no

Un dispositivo TUN è un'interfaccia IP, ed è questo che lo rende instradabile. OpenVPN consegna al client un indirizzo e un insieme di rotte, e da lì in poi il client invia datagrammi a un peer. Nulla in quel modello crea un collegamento condiviso dove ogni host sente ogni frame.

Il traffico di scoperta non si adatta affatto a quel modello. Le vecchie query di nome di Windows, gli annunci SSDP e le richieste mDNS vengono inviati a tutti su un segmento invece che a una sola destinazione. Un collegamento instradato non ha nessun «tutti» a cui inviare. Ognuno di questi meccanismi presuppone un mezzo condiviso.

Il tunnel può quindi essere sano mentre la scoperta fallisce del tutto. È quella la frase a cui aggrapparsi quando qualcuno segnala che la VPN è giù.

Il bridging funziona eliminando il confine

Un dispositivo TAP trasporta frame, e un bridge lo collega a un segmento LAN reale. Il client ha allora un indirizzo su quel segmento e sente il suo traffico broadcast. Per questo il bridging sembra curare il problema dei nomi. Rende anche il client dipendente da quel segmento per l'indirizzamento.

La cura è la rimozione del confine di instradamento, non una nuova capacità di nomi dentro il tunnel. Tutto ciò che il segmento trasmette in broadcast ora attraversa anche il collegamento.

Per un piccolo laboratorio è uno scambio equo. Su una forza lavoro distribuita raramente lo è.

Spingere DNS e WINS è la riparazione più stretta

Date al client un posto preciso dove chiedere. dhcp-option DNS e dhcp-option DOMAIN puntano i nomi interni a un server che conosce la zona, e un client Windows che si affida ancora a NetBIOS può ricevere un server WINS allo stesso modo. Il tunnel resta instradato e il segmento resta dove deve stare.

Due condizioni decidono se funziona. Il server indicato deve rispondere per la zona, e la query deve essere consentita attraverso il tunnel.

Provate il resolver dal client invece che dalla shell del server stesso. Un resolver che funziona in locale non dice nulla su ciò che trasporta il tunnel.

Scoprite quale livello è fallito

Fate prima ping all'indirizzo, poi risolvete il nome e leggete quale server ha risposto. Una risposta negativa da un server che non ospita la zona appare diversa da una query che non ha mai lasciato la macchina. Un nome che si risolve ma rifiuta le connessioni è un terzo problema del tutto.

Il multicast sta dietro lo stesso muro. Un gruppo come 224.0.0.251 non viene inoltrato su un tunnel instradato per impostazione predefinita, e una rotta per il gruppo non basta senza un percorso consapevole del multicast o un riflettore sulla LAN.