Come leggere l'instradamento DNS della VPN per collegamento da resolvectl

Eseguite resolvectl status e ottenete un muro di blocchi per collegamento, ciascuno con i propri server e la propria riga di domini. La riga che decide l'instradamento è l'elenco dei domini, non l'indirizzo del server dei nomi, perché lo stub locale inoltra ogni richiesta al collegamento che rivendica il nome. Leggete queste rivendicazioni prima di leggere la risposta, poi interrogate il nome e controllate quale collegamento lo ha prodotto. Una risposta sbagliata dal collegamento giusto è un problema diverso da una risposta giusta dal collegamento sbagliato.

Che cosa vi dice ogni blocco per collegamento

Ogni blocco elenca i server che il resolver userà per quell'interfaccia, l'elenco dei domini e se il collegamento è la rotta predefinita. L'elenco dei domini è un insieme di rivendicazioni, e il resolver applica la corrispondenza del suffisso più lungo: una richiesta per host.corp.example è rivendicata da un collegamento che porta corp.example prima di uno che porta solo la rotta predefinita. Due collegamenti che rivendicano lo stesso suffisso lasciano l'esito alla priorità e all'ordine, perciò i duplicati meritano attenzione per primi. La riga del server corrente mostra quale dei server elencati è in uso in quel momento.

Un indirizzo stub come 127.0.0.53 in /etc/resolv.conf dice solo che lo stub è davanti. Non nomina l'origine che ha risposto, perciò una diagnosi basata solo su resolv.conf si blocca.

Leggete correttamente i tre tipi di voce di dominio

La tilde cambia il comportamento di ricerca, non l'instradamento. Una voce senza tilde è sia dominio di instradamento sia dominio di ricerca, quindi i nomi sotto di essa vengono inviati a quel collegamento e ai nomi a etichetta singola viene aggiunto il suffisso. Una voce con tilde instrada lo stesso suffisso ma lo tiene fuori dall'elenco di ricerca. Perciò togliere una tilde cambia quali nomi nudi si risolvono, e perciò una tilde mancante è un problema di ricerca e non un guasto del DNS diviso.

La voce di rotta predefinita rivendica tutto ciò che nessun altro collegamento copre. Un profilo a tunnel completo di solito la vuole e un profilo diviso di solito no, perché allora i nomi pubblici viaggiano verso il resolver privato e possono fallire lì. Leggete la tabella rispetto all'intento del profilo invece di copiare flag tra profili. Quando due collegamenti rivendicano lo stesso suffisso, risolvete la questione di priorità prima di modificare qualsiasi altra cosa.

Interrogate un nome e vedete quale collegamento ha risposto

Il sottocomando query stampa l'indirizzo, il protocollo e il collegamento o l'ambito che hanno prodotto la risposta. Provate un nome che dovrebbe essere rivendicato dal suffisso privato e un nome pubblico ordinario, poi confrontate le origini riportate. Se il nome privato risponde dal collegamento wireless, la rivendicazione manca o il tunnel è inattivo; se un nome pubblico su un profilo diviso risponde dal tunnel, la rotta predefinita è troppo ampia. Questi due guasti sembrano identici in un browser e opposti in questo output.

resolvectl status
resolvectl query host.corp.example

Osservate anche il protocollo riportato, perché una risposta dalla cache o dal file hosts può arrivare senza che sia stata interrogata alcuna origine. Una risposta dalla cache dimostra che il nome si è risolto in qualche momento, non che la politica attuale lo instradi correttamente.

Tenete l'instradamento dei nomi separato dall'instradamento dei pacchetti

Una decisione del resolver non crea un percorso. Il server scelto ha ancora bisogno di una rotta verso il suo indirizzo, e l'indirizzo restituito ha ancora bisogno di una rotta verso la rete privata, quindi una politica DNS corretta può convivere con una connessione che non si apre mai. Quando un nome si risolve e l'applicazione fallisce, esaminate l'indirizzo e la rotta invece di cambiare di nuovo il DNS. Risoluzione dei nomi e raggiungibilità sono due domande con due proprietari diversi.

Le applicazioni possono aggirare del tutto il resolver di sistema tramite la propria impostazione di DNS sicuro o un resolver integrato. Il risultato di resolvectl descrive il percorso di sistema, e un browser che lo ignora sarà in disaccordo con ogni prova che fate. Controllate quell'impostazione prima di concludere che la politica è rotta.

Annotate l'indirizzo a cui il nome si è risolto accanto al collegamento. Un nome corretto che punta all'indirizzo sbagliato è un problema di record, non di instradamento.

Ricontrollate dopo che il collegamento è cambiato

Una riconnessione o un cambio di rete wireless ricostruisce lo stato del collegamento, e un gestore di rete può reinstallare i propri domini e server sopra tutto ciò che è stato impostato a mano. Interrogate poi gli stessi due nomi e confrontate con la linea di base registrata. Se una modifica manuale è sparita, la correzione appartiene al profilo di connessione e non a un comando shell. È la registrazione prima e dopo che lo rende visibile.

Condividete solo i nomi e il contesto dei server che il rapporto richiede, perché i suffissi interni rivelano la topologia. La documentazione di systemd-resolved sull'instradamento dei domini copre la regola della corrispondenza più lunga e il comportamento della tilde, e leggerla una volta evita la maggior parte degli errori della tabella qui sopra: instradamento delle richieste in systemd-resolved.