No hay conectividad de red en el contenedor LXC configurado en el modo "enrutado"

Question 1

Se requieren varias cosas para que su esquema funcione:

Verifique el reenvío en las interfaces del host: ip -4 netconf show dev vetha8400046y ip -4 netconf show dev eth0. Deberías ver el reenvío habilitado en el resultado. De lo contrario, habilítelo con el sysctl -w net.ipv4.conf.<iface>.forwarding=1comando. Agregue las cadenas correspondientes al /etc/sysctl.confarchivo para hacerlo persistente.
Verifique la ruta en el host: ip -4 route get 8.8.8.8 from 192.168.33.11 iif vetha8400046. Deberías ver la ruta válida a través de tu puerta de enlace predeterminada ( ... via 10.0.2.2 dev .... Verifica también la ruta inversa con el archivo ip -4 route get 192.168.33.11 from 8.8.8.8 iif eth0.
Haga ping al contenedor desde el host y viceversa.
Configure la NAT en el host: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Haga ping a algún host externo desde el contenedor. Los contadores de esta regla en el iptables-save -cdeben ser distintos de cero.
Haga la pregunta si se quedó atascado.

Answer

Se requieren varias cosas para que su esquema funcione:

Verifique el reenvío en las interfaces del host: ip -4 netconf show dev vetha8400046y ip -4 netconf show dev eth0. Deberías ver el reenvío habilitado en el resultado. De lo contrario, habilítelo con el sysctl -w net.ipv4.conf.<iface>.forwarding=1comando. Agregue las cadenas correspondientes al /etc/sysctl.confarchivo para hacerlo persistente.
Verifique la ruta en el host: ip -4 route get 8.8.8.8 from 192.168.33.11 iif vetha8400046. Deberías ver la ruta válida a través de tu puerta de enlace predeterminada ( ... via 10.0.2.2 dev .... Verifica también la ruta inversa con el archivo ip -4 route get 192.168.33.11 from 8.8.8.8 iif eth0.
Haga ping al contenedor desde el host y viceversa.
Configure la NAT en el host: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Haga ping a algún host externo desde el contenedor. Los contadores de esta regla en el iptables-save -cdeben ser distintos de cero.
Haga la pregunta si se quedó atascado.

Question 2

Esta es la configuración correcta para que los contenedores de Debian 10 sean accesibles en nuestra red local mediante sus propias IP estáticas y que tengan acceso a Internet.

Nuestro Vagrantfile:

Vagrant.configure("2") do |config|

  config.vm.define "main" do |main|
    main.vm.box = "bento/ubuntu-20.04"
    main.vm.box_version = "202010.24.0"
    main.vm.hostname = "lxc-host"

    main.vm.network "public_network", auto_config: false

    main.vm.provision "shell",
      run: "always",
      inline: "ip address add **192.168.1.200**/24 dev eth1"
    main.vm.provision "shell",
      run: "always",
      inline: "ip link set eth1 up"

    main.vm.provider :virtualbox do |vb|
        vb.memory = 1024
    end
  end

end

Tenga en cuenta que estamos configurando una red "pública", lo que significa que al iniciar Vagrant, se le pedirá que elija la interfaz que desea usar, elija la que está utilizando para conectarse a su red local.

Tenga en cuenta también que estamos configurando una sola IP por ahora, esta (192.168.1.200) será la IP de nuestro host.No estamos configurando la IP del contenedor aquí.

Luego de iniciar nuestro host, habilite el reenvío de IP en su configuración, descomentando: net.ipv4.ip_forward=1in /etc/sysctl.confy reiniciando sysctl ejecutando systemctl restart systemd-sysctl.

Ahora, asumiendo que instaló y configuró LXDcorrectamente en el host, puede iniciar lxdcon la siguiente configuración:

config:
  core.https_address: '[::]:8443'
  core.trust_password: true
networks: []
storage_pools:
- config:
    source: [path-to-storage-pools-directory]
  description: ""
  name: default
  driver: dir
profiles:
- name: default
  config:
  description: ""
  devices:
    root:
      path: /
      pool: default
      type: disk
- name: test-container
  config:
    user.user-data: |
      #cloud-config
      bootcmd:
        - echo 'nameserver 8.8.8.8' > /etc/resolvconf/resolv.conf.d/tail
        - systemctl restart resolvconf
  description: Mail Server LXD profile
  devices:
    eth0:
      ipv4.address: 192.168.1.201
      nictype: routed
      parent: eth1
      type: nic
cluster: null

Cambiar[ruta-al-directorio-de-grupos-de-almacenamiento]en la ruta real al directorio donde va a almacenar sus grupos.

Tenga en cuenta que no estamos utilizando cloud-init para configurar la red, ya que colisionaría con el servicio de red de Debian y no podría iniciarse.

Tenga en cuenta también que estamos usando cloud-init para configurar el servidor de nombres para que lo utilice nuestro invitado.

192.168.1.201 será la IP de nuestro huésped. Esta configuración supone que la red local es 192.168.1.0; si su red es diferente, cambie las IP en consecuencia. También asegúrese de que las IP utilizadas aquí no sean utilizadas por nada más en la red.

Estamos usando dos perfiles aquí, pero depende de usted cómo organiza su configuración.

Ahora ejecutemos nuestro contenedor:

lxc launch images:debian/10/cloud our-actual-test-container --profile default --profile test-container

Debería estar ejecutándose y disponible en la red local, pero no tendrá acceso a Internet, y esa es la parte complicada. Esto se debe al enrutamiento configurado por el lxdbasado en la suposición de que la puerta de enlace predeterminada es la de la red vagrant/virtualbox. Necesitamos arreglar eso.

Al ejecutar ip ren el host, debería ver la lista de rutas, algo así:

default via 10.0.2.2 dev eth0 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 
10.0.2.2 dev eth0 proto dhcp scope link src 10.0.2.15 metric 100 
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.200 
192.168.1.201 dev vethc5cebe03 scope link

El problema está en el predeterminado, que enruta el tráfico a la red vagrant/virtualbox en lugar de a nuestra puerta de enlace real. Eliminémoslo:

ip route del default via 10.0.2.2

Y agreguemos la regla que reenviará los paquetes a la puerta de enlace real de nuestra red local:

ip route add default via 192.168.1.1

(asumiendo que 192.168.1.1 es la IP de nuestra puerta de enlace local)

Ahora el tráfico del contenedor irá a la puerta de enlace correcta y ¡listo!

Answer