Nenhuma conectividade de rede no contêiner LXC configurada no modo "roteado"

Question 1

Existem várias coisas necessárias para fazer seu esquema funcionar:

Verifique o encaminhamento nas interfaces do host: ip -4 netconf show dev vetha8400046e ip -4 netconf show dev eth0. Você deverá ver o encaminhamento habilitado na saída. Caso contrário, habilite-o com o sysctl -w net.ipv4.conf.<iface>.forwarding=1comando. Adicione as strings correspondentes ao /etc/sysctl.confarquivo para torná-lo persistente.
Verifique o roteamento no host: ip -4 route get 8.8.8.8 from 192.168.33.11 iif vetha8400046. Você deverá ver a rota válida através do seu gateway padrão ( ... via 10.0.2.2 dev .... Verifique também a rota reversa com o ip -4 route get 192.168.33.11 from 8.8.8.8 iif eth0.
Faça ping no contêiner do host e vice-versa.
Configure o NAT no host: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Faça ping em algum host externo do contêiner. Os contadores desta regra iptables-save -cdevem ser diferentes de zero.
Faça a pergunta se você travou.

Answer

Existem várias coisas necessárias para fazer seu esquema funcionar:

Verifique o encaminhamento nas interfaces do host: ip -4 netconf show dev vetha8400046e ip -4 netconf show dev eth0. Você deverá ver o encaminhamento habilitado na saída. Caso contrário, habilite-o com o sysctl -w net.ipv4.conf.<iface>.forwarding=1comando. Adicione as strings correspondentes ao /etc/sysctl.confarquivo para torná-lo persistente.
Verifique o roteamento no host: ip -4 route get 8.8.8.8 from 192.168.33.11 iif vetha8400046. Você deverá ver a rota válida através do seu gateway padrão ( ... via 10.0.2.2 dev .... Verifique também a rota reversa com o ip -4 route get 192.168.33.11 from 8.8.8.8 iif eth0.
Faça ping no contêiner do host e vice-versa.
Configure o NAT no host: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Faça ping em algum host externo do contêiner. Os contadores desta regra iptables-save -cdevem ser diferentes de zero.
Faça a pergunta se você travou.

Question 2

Esta é a configuração correta para ter contêineres Debian 10 acessíveis em nossa rede local por seus próprios IPs estáticos e ter acesso à Internet.

Nosso 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

Observe que estamos configurando uma rede "pública", isso significa que ao iniciar o Vagrant, você será solicitado a escolher a interface a ser usada, escolha aquela que você está usando para se conectar à sua rede local.

Observe também que estamos configurando apenas um único IP por enquanto, este (192.168.1.200) será o IP do nosso host.Não estamos configurando o IP do contêiner aqui.

Após iniciar nosso host, habilite o encaminhamento de IP em sua configuração, descomentando: net.ipv4.ip_forward=1in /etc/sysctl.confe reiniciando o sysctl executando systemctl restart systemd-sysctl.

Agora, supondo que você instalou e configurou LXDcorretamente no host, você pode iniciar lxdcom a seguinte configuração:

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

Mudar[caminho para o diretório dos pools de armazenamento]no caminho real para o diretório onde você armazenará seus pools.

Observe que não estamos usando o cloud-init para configurar a rede, pois ele colidiria com o serviço de rede do Debian, fazendo com que ele não iniciasse.

Observe também que estamos usando o cloud-init para configurar o servidor de nomes a ser usado pelo nosso convidado.

192.168.1.201 será o IP do nosso convidado. Esta configuração assume que a rede local é 192.168.1.0, se a sua rede for diferente, altere os IPs de acordo. Certifique-se também de que os IPs usados aqui não sejam usados por mais nada na rede.

Estamos usando dois perfis aqui, mas depende de você como organizar sua configuração.

Agora vamos executar nosso contêiner:

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

Ele deveria estar rodando e disponível na rede local, mas não terá acesso à internet, e essa é a parte complicada. Isso é causado pelo roteamento configurado com lxdbase na suposição de que o gateway padrão é aquele para a rede vagrant/virtualbox. Precisamos consertar isso.

Ao executar ip rno host, você deverá ver a lista de rotas - algo assim:

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

O problema está no padrão, que roteia o tráfego para a rede vagrant/virtualbox em vez de nosso gateway real. Vamos removê-lo:

ip route del default via 10.0.2.2

E vamos adicionar a regra que encaminhará os pacotes para o gateway real da nossa rede local:

ip route add default via 192.168.1.1

(assumindo que 192.168.1.1 seja o IP do nosso gateway local)

Agora o tráfego do contêiner irá para o gateway correto e pronto!

Answer