Compartir a rede dun contedor VPN: que pasa co DNS

Compartir o espazo de nomes de rede dun contedor VPN dá á túa aplicación as interfaces e as rutas do túnel. Non lle dá o resolutor do túnel, nin unha copia fusionada de calquera outra cousa no host. Esa fenda produce un fallo moi concreto: os nomes públicos resólvense, os internos non, e a aplicación que falla parece estar usando o servidor DNS incorrecto, porque o está. A reparación adoita ser máis pequena do que suxire o diagnóstico.

Paso 1: Proba desde a aplicación, non desde o host

Executa a consulta dentro do contedor que ten o problema, non no host e non nun navegador. docker exec app-container getent hosts db.internal responde á única pregunta que importa: que devolve o resolutor deste proceso.

Se o host resolve o nome e o contedor non, atopaches o fallo. Todo o demais é escoller unha forma admitida de arranxalo.

Paso 2: Le o modelo admitido do runtime

A documentación de redes de Docker rexistra restricións nas opcións de DNS para contedores que comparten o modo de rede doutro contedor. En Compose network_mode: service:vpn vincula a aplicación ao espazo de nomes do contedor VPN, e por servizo dns a configuración non se comporta como nun servizo normal. A resolución que obtés é a que ten o espazo de nomes compartido.

As redes de ponte definidas polo usuario tamén usan o DNS integrado de Docker de forma distinta á ponte predeterminada. Por iso unha dns cláusula copiada dun exemplo de ponte que funciona pode non facer absolutamente nada nunha pila compartida. Comproba a disposición antes de copiar a cláusula.

Un enderezo de bucle invertido sempre se refire ao contexto de rede correspondente. Dentro dun espazo de nomes compartido, 127.0.0.1 non é o resolutor do host.

Paso 3: Segue a consulta ata o seu destinatario

Le a configuración do resolutor da aplicación e, despois, calquera DNS cifrado específico da aplicación que esta inclúa, porque unha aplicación que executa o seu propio resolutor ignora o ficheiro que ediches. Despois comproba se o resolutor elixido é alcanzable baixo as rutas e a política de devasas da VPN. Un enderezo de resolutor na outra beira do túnel é inútil se o espazo de nomes non ten ruta ata el. Confirma o destinatario antes de editar calquera ficheiro.

Unha páxina de comprobación de IP do navegador non pode dicirche onde foron as consultas de nomes. Diche onde foi unha conexión HTTP.

Paso 4: Arranxa as dúas clases de fallo de forma distinta

Se fallan os nomes de servizo mentres os nomes públicos funcionan, o problema é o descubrimento de servizos dentro da rede de contedores, non a lista de resolutores públicos. Cambiar todos os enderezos DNS públicos non creará rexistros que o mecanismo de descubrimento da rede nunca recibiu a petición de crear.

Se fallan as dúas clases, comeza pola accesibilidade ao resolutor. Se só falla unha, comeza polo mecanismo de descubrimento. As dúas teñen propietarios distintos, por iso unha reparación nunca cobre as dúas.

Paso 5: Volve probar tras recrear

Cambia a configuración mediante o mecanismo admitido do runtime e despois recrea os contedores en lugar de editar ficheiros dentro dun en execución. Proba un nome privado novo, un nome público novo e a petición da aplicación que segue a consulta. Unha edición en /etc/resolv.conf dentro dun contedor desaparece ao recrealo e convencerate de que a reparación funcionou cando non o fixo.

Anota o propietario do resolutor e o espazo de nomes esperado xunto á definición da rede compartida. A seguinte persoa necesitará ambos.