mDNS dentro una VPN: perché i nomi .local non si risolvono

La stampante dell’ufficio compare in ogni applicazione sulla scrivania e sparisce sulla VPN, anche se potete fare ping all’indirizzo che sapete che ha. Nulla nel tunnel è rotto: scoperta e raggiungibilità sono servizi separati, e solo uno dei due attraversa un tunnel instradato per impostazione predefinita. I controlli qui sotto li separano prima che iniziate ad aggiungere rotte. Una rotta non può sistemare una query che non ha mai lasciato il collegamento.

Verificate cosa si risolve oggi e cosa sembra solo risolto

Separate prima le due domande: una query unicast per un nome host interroga un resolver, mentre una ricerca di _ipp._tcp interroga il collegamento locale. Su Linux, avahi-browse -a mostra cosa può vedere il DNS multicast, e resolvectl query name.local mostra cosa fa lo stack dei resolver con quel nome. Su macOS, dns-sd -B _ipp._tcp elenca i servizi scoperti senza bisogno di un indirizzo prima.

Se l’indirizzo risponde e il nome no, l’instradamento funziona e la scoperta no. Un nome .local può anche essere risolto sull’host stesso tramite nss-mdns senza avahi-browse installato, quindi un getent o un ping riuscito a quel nome non è prova che la scoperta abbia attraversato il tunnel; il risultato della ricerca e quello del resolver sono prove diverse. Le applicazioni mettono in cache ciò che hanno scoperto, ed è per questo che il guasto appare spesso ore dopo la connessione e non al momento della connessione. Chiudete e riaprite l’applicazione, poi controllate se la voce in cache contiene un nome o un indirizzo, perché un indirizzo continua a funzionare molto dopo che la scoperta si è fermata.

Perché la query non attraversa mai il tunnel

Il DNS multicast invia le query a 224.0.0.251, all’interno del blocco di controllo della rete locale, sulla porta UDP 5353. I router non inoltrano gli indirizzi di quel blocco, quindi la query resta sul collegamento a cui è stata inviata. I mittenti impostano anche il TTL IP, o il limite di hop IPv6, a 255 perché il destinatario possa rifiutare un pacchetto che ha già attraversato un router; è così che il protocollo rileva lo spoofing fuori dal collegamento, non è così che resta locale. La località deriva dall’indirizzo di destinazione, non da un TTL di un solo hop.

Anche il tipo di tunnel conta. Un’interfaccia in stile tun trasporta pacchetti IP e nulla più, quindi nessun gruppo multicast le sopravvive. Un bridge in stile tap estende il dominio di broadcast stesso, ed è per questo che alcuni progetti vecchi facevano bridge invece di instradare, ed ereditavano ogni problema che il bridge porta.

Un’eccezione per LAN attendibile non cambia nulla di questo, perché decide quale traffico può usare il tunnel invece di insegnare al tunnel a inoltrare il multicast. Il pacchetto continua a non avere un segmento condiviso su cui essere ascoltato.

Scegliete un progetto di denominazione che potete mantenere

Per le risorse aziendali la risposta duratura è un nome host instradato servito dal resolver che la VPN spinge, con DNS diviso perché i nomi interni vadano ai server interni e tutto il resto no. Windows lo espone come tabella dei criteri di risoluzione dei nomi, macOS usa resolver con ambito per interfaccia, e la maggior parte dei client ha un’impostazione di push equivalente. Il dispositivo mantiene il suo nome abituale nel DNS interno, e la scoperta smette di far parte del percorso.

Un proxy di scoperta o un riflettore mDNS può colmare il divario, ed è un progetto reale con il proprio host, la propria esposizione e i propri requisiti client. Non compare perché avete aggiunto una rotta. Non inoltrate mai query .local a un resolver pubblico: il dominio è riservato all’uso multicast locale da RFC 6762, e inviarlo verso l’esterno produce errori lenti e una divulgazione inutile di dati.

Verificate il servizio, non il nome

Un nome in un elenco di ricerca prova il passo di scoperta, non che il servizio risponda. Aprite la coda di stampa o l’interfaccia web e completate un’operazione reale, poi ripetetela dopo una riconnessione.

La scoperta mette in cache i nomi in modo aggressivo, quindi una voce obsoleta può sembrare un successo. Se compare un certificato o una richiesta di autenticazione, è il livello successivo e un problema a parte. Annotate quale meccanismo avete cambiato, resolver o scoperta, perché la persona successiva non debba riaprire tutta la questione.