Acesso à Internet no contêiner LXC com nftables

2

Atualmente, estou tentando fornecer um acesso à Internet do contêiner LXC usando nftables, mas parece que não consigo acertar em absoluto.

A configuração é a seguinte: O host tem uma interface WAN (enp1s0) e uma ponte (lxcbrd). Eu não estou usando lxc-net, mas uma ponte que eu fiz da seguinte forma:

allow-hotplug enp1s0
iface enp1s0 inet dhcp

auto lxcbrd
iface lxcbrd inet static
        bridge_ports none
        bridge_fd 0
        bridge_maxwait 0
        address 10.0.0.254
        netmask 255.255.255.0

O contêiner LXC é configurado para usar lxcbrd ...

lxc.network.type = veth
lxc.network.link = lxcbrd
lxc.network.ipv4 = 10.0.0.1/24
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:98:34:26
lxc.network.ipv4.gateway = auto

... e parece que até certo ponto:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
    inet [REDACTED] brd [REDACTED] scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 [REDACTED] scope link 
       valid_lft forever preferred_lft forever
3: lxcbrd: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:5f:9a:9b:75:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.254/24 brd 10.0.0.255 scope global lxcbrd
       valid_lft forever preferred_lft forever
    inet6 fe80::6414:77ff:fe2d:6699/64 scope link 
       valid_lft forever preferred_lft forever
5: vethPPYOVI@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbrd state UP group default qlen 1000
    link/ether fe:5f:9a:9b:75:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fc5f:9aff:fe9b:75a4/64 scope link 
       valid_lft forever preferred_lft forever

No host, nftables é configurado para nat e forward:

table ip nat {
        chain prerouting {
                type nat hook prerouting priority 0; policy accept;
        }

        chain postrouting {
                type nat hook postrouting priority 0; policy accept;
                oifname "enp1s0" masquerade
        }
}
table inet filter {
        chain input {
                type filter hook input priority 0; policy drop;
                ct state { established, related} accept comment "accept all traffic originated from us"
                ct state invalid drop comment "drop invalid packets"
                iif "lo" accept comment "accept all loopback traffic"
                icmp type { router-advertisement, destination-unreachable, parameter-problem, time-exceeded} accept comment "ICMP"
                icmpv6 type { nd-neighbor-solicit, time-exceeded, destination-unreachable, packet-too-big, nd-neighbor-advert, parameter-problem, nd-router-advert} accept comment "ICMPv6"
                tcp dport 2222 ct state new accept comment "ssh"
                udp dport 60000-61000 ct state new accept comment "mosh"
        }

        chain forward {
                type filter hook forward priority 0; policy accept;
                iifname "lxcbrd" oifname "enp1s0" accept
                iifname "enp1s0" oifname "lxcbrd" accept
        }

        chain output {
                type filter hook output priority 0; policy accept;
        }
}

De dentro do contêiner:

6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:98:34:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe98:3426/64 scope link 
       valid_lft forever preferred_lft forever

No entanto, não tenho acesso à Internet de dentro do contêiner. Do host, posso pingar o contêiner sem qualquer problema.

UPDATE: com esta configuração, eu não consigo nem pingar o gateway (que é 10.0.0.254), mas posso pingar outro container na mesma sub-rede (10.0.0.0/24). Se eu definir nftables chain inet filter input para policy accept, posso fazer ping no gateway, mas não em um IP fora da sub-rede (como 8.8.8.8); Eu não tenho certeza do porque se comporta assim considerando a regra que deveria permitir todo o tráfego icmp.

UPDATE2: depois de um echo 1 > /proc/sys/net/ipv4/ip_forward (eu tinha certeza que já defini isso em /etc/sysctl.conf ... aparentemente não), sou capaz de fazer ping de IPs WAN (como 8.8.8.8) e resolver DNS depois adicionando manualmente os servidores DNS do Google em /etc/resolv.conf. No entanto, não consigo executar ping no gateway, que é o endereço da interface da bridge (10.0.0.254), se a entrada do filtro inetables chain inet estiver definida como drop da política.

Alguém vê algo extremamente errado com minha configuração?

Obrigado pela ajuda!

    
por liquid 06.12.2017 / 18:25

0 respostas