Tengo Lxd instalado en un sistema Arch (de paquetes, no de snapd), ayer reinicié el sistema después de una actualización y la resolución del nombre del dominio falso .lxd dejó de funcionar; dns se proporciona en 10.0.10.1 desde dnsmasq, lanzado por el servicio lxc-net. dnsmasq también se utiliza para proporcionar un dominio interno a otros hosts de la red y esto funciona bien. con netstat -lnppuedo ver ambas instancias de dnsmasq vinculadas en las direcciones correctas, pero:
- cuando hago ping a un contenedor (por ejemplo
ping proxy.lxd, ) desde otro, la IP de la tarjeta de red principal del host se resuelve (192.168.1.63) y el ping funciona. - al hacer ping directamente a la dirección IP del otro contenedor, funciona.
- da el mismo comando en el host
ping: proxy.lxd: Name or service unknown.
El dnsmasq del sistema (no el iniciado por lxc-net) está configurado con: server=/lxd/10.0.10.1y funcionó bien hasta ayer.
La actualización no involucró dnsmasq o el script lxc-net, pero hubo una actualización de lxd de 4.8-1 a 4.9-1.
Parece estar relacionado de alguna manera con dnsmasq, pero no pude encontrar una manera de entenderlo y resolverlo.
La red funciona bien tanto en contenedores como en host, solo dns fue a... /dev/null ¿Le pasó esto a alguien? ¿Cómo puedo resolverlo?
Respuesta1
Bueno, de alguna manera fue mi culpa. Todavía no sé por qué sucedió, pero después de investigar un poco, no puedo decir honestamente cómo funcionaba antes. Dicho esto, la "solución" eraconfigurarel sistema :)
Deshabilité el script lxc-net utilizado anteriormente para configurar el puente de red.ydnsmasq, entonces:
lxc network create bridgenamecrear el puente y gestionarlo en lxd;lxc network edit bridgenameconfigurarlo;- agregó el puente al perfil predeterminado (
lxc profile edit default); - configurado
/etc/dnsmasq.confpara escuchar en 127.0.0.1, la dirección NIC y la dirección del puente, configure dhcp solo para la dirección del puente, agregadolocal=/lxd/para resolver container.lxd.
entoncesfuncionó.