Condividere la rete di un container VPN: cosa succede al DNS

Condividere lo spazio dei nomi di rete di un container VPN dà alla tua applicazione le interfacce e le rotte del tunnel. Non le dà il resolver del tunnel, né una copia unificata di qualcos’altro sull’host. Questo divario produce un guasto molto specifico: i nomi pubblici si risolvono, quelli interni no, e l’applicazione che fallisce sembra usare il server DNS sbagliato, perché è così. La riparazione è di solito più piccola di quanto suggerisca la diagnosi.

Passo 1: Verifica dall’applicazione, non dall’host

Esegui la ricerca dentro il container che ha il problema, non sull’host e non in un browser. docker exec app-container getent hosts db.internal risponde all’unica domanda che conta: cosa restituisce il resolver di questo processo.

Se l’host risolve il nome e il container no, hai trovato il guasto. Tutto il resto è scegliere un modo supportato per ripararlo.

Passo 2: Leggi il modello supportato dal runtime

La documentazione di rete di Docker registra restrizioni sui flag DNS per i container che condividono la modalità di rete di un altro container. In Compose network_mode: service:vpn lega l’applicazione allo spazio dei nomi del container VPN, e per servizio dns le impostazioni non si comportano come per un servizio ordinario. La risoluzione che ottieni è quella che ha lo spazio dei nomi condiviso.

Anche le reti bridge definite dall’utente usano il DNS integrato di Docker in modo diverso dal bridge predefinito. È per questo che una dns clausola copiata da un esempio di bridge funzionante può non fare assolutamente nulla in uno stack condiviso. Controlla la configurazione prima di copiare la clausola.

Un indirizzo di loopback si riferisce sempre al contesto di rete pertinente. Dentro uno spazio dei nomi condiviso, 127.0.0.1 non è il resolver dell’host.

Passo 3: Segui la query fino al suo destinatario

Leggi la configurazione del resolver dell’applicazione, poi qualsiasi DNS cifrato specifico dell’applicazione che essa porta con sé, perché un’applicazione che esegue il proprio resolver ignora il file che hai modificato. Poi controlla se il resolver scelto è raggiungibile con le rotte e la politica del firewall della VPN. Un indirizzo di resolver dall’altra parte del tunnel è inutile se lo spazio dei nomi non ha una rotta verso di esso. Conferma il destinatario prima di modificare qualsiasi file.

Una pagina di controllo IP nel browser non può dirti dove sono andate le query dei nomi. Ti dice dove è andata una connessione HTTP.

Passo 4: Ripara le due classi di guasto in modo diverso

Se i nomi dei servizi falliscono mentre i nomi pubblici funzionano, il problema è l’individuazione dei servizi nella rete dei container, non l’elenco dei resolver pubblici. Cambiare ogni indirizzo DNS pubblico non creerà record che il meccanismo di scoperta della rete non è mai stato pregato di creare.

Se falliscono entrambe le classi, inizia dalla raggiungibilità del resolver. Se ne fallisce solo una, inizia dal meccanismo di scoperta. I due hanno proprietari diversi, per questo una riparazione non copre mai entrambe.

Passo 5: Riprova dopo la ricreazione

Cambia la configurazione tramite il meccanismo supportato dal runtime, poi ricrea i container invece di modificare file dentro uno in esecuzione. Prova un nuovo nome privato, un nuovo nome pubblico e la richiesta dell’applicazione che segue la ricerca. Una modifica in /etc/resolv.conf dentro un container scompare alla ricreazione e ti convincerà che la riparazione ha funzionato quando non l’ha fatto.

Annota il proprietario del resolver e lo spazio dei nomi atteso accanto alla definizione della rete condivisa. La prossima persona avrà bisogno di entrambi.