Compartir la xarxa d’un contenidor VPN: què passa amb el DNS

Compartir l’espai de noms de xarxa d’un contenidor VPN dona a la teva aplicació les interfícies i les rutes del túnel. No li dona el resolutor del túnel, ni una còpia fusionada de res més de l’amfitrió. Aquest buit produeix una fallada molt concreta: els noms públics es resolen, els interns no, i l’aplicació que falla sembla que faci servir el servidor DNS equivocat, perquè és així. La reparació sol ser més petita del que suggereix el diagnòstic.

Pas 1: Prova des de l’aplicació, no des de l’amfitrió

Executa la consulta dins del contenidor que té el problema, no a l’amfitrió ni al navegador. docker exec app-container getent hosts db.internal respon l’única pregunta que importa: què retorna el resolutor d’aquest procés.

Si l’amfitrió resol el nom i el contenidor no, has trobat la fallada. Tot el que ve després és triar una manera admesa d’arreglar-ho.

Pas 2: Llegeix el model admès del runtime

La documentació de xarxes de Docker recull restriccions sobre els indicadors DNS per als contenidors que comparteixen el mode de xarxa d’un altre contenidor. A Compose, network_mode: service:vpn lliga l’aplicació a l’espai de noms del contenidor VPN, i per servei dns la configuració no es comporta com en un servei normal. La resolució que obtens és la que té l’espai de noms compartit.

Les xarxes de pont definides per l’usuari també fan servir el DNS integrat de Docker de manera diferent del pont per defecte. Per això una dns clàusula copiada d’un exemple de pont que funciona pot no fer absolutament res en una pila compartida. Comprova la disposició abans de copiar la clàusula.

Una adreça de bucle de retorn sempre es refereix al context de xarxa corresponent. Dins d’un espai de noms compartit, 127.0.0.1 no és el resolutor de l’amfitrió.

Pas 3: Segueix la consulta fins al seu destinatari

Llegeix la configuració del resolutor de l’aplicació i, després, qualsevol DNS xifrat específic de l’aplicació que aquesta inclogui, perquè una aplicació que executa el seu propi resolutor ignora el fitxer que has editat. Després comprova si el resolutor seleccionat és abastable sota les rutes i la política de tallafocs de la VPN. Una adreça de resolutor a l’altre costat del túnel és inútil si l’espai de noms no hi té cap ruta. Confirma el destinatari abans d’editar qualsevol fitxer.

Una pàgina de comprovació d’IP del navegador no et pot dir on han anat les consultes de noms. Et diu on ha anat una connexió HTTP.

Pas 4: Repara les dues classes de fallada de manera diferent

Si fallen els noms de servei mentre els noms públics funcionen, el problema és el descobriment de serveis dins de la xarxa de contenidors, no la llista de resolutors públics. Canviar totes les adreces DNS públiques no crearà registres que el mecanisme de descobriment de la xarxa mai no ha estat demanat de crear.

Si fallen les dues classes, comença per l’abastabilitat del resolutor. Si només en falla una, comença pel mecanisme de descobriment. Les dues tenen propietaris diferents, i per això una reparació mai no cobreix les dues.

Pas 5: Torna a provar després de recrear

Canvia la configuració mitjançant el mecanisme admès del runtime i després recrea els contenidors en lloc d’editar fitxers dins d’un de funcionament. Prova un nom privat nou, un nom públic nou i la petició de l’aplicació que segueix la consulta. Una edició a /etc/resolv.conf dins d’un contenidor desapareix en recrear-lo i et convencerà que la reparació ha funcionat quan no ho ha fet.

Anota el propietari del resolutor i l’espai de noms esperat al costat de la definició de la xarxa compartida. La propera persona necessitarà tots dos.