☰

Roteamento Linux com duas NICs (LAN vs Internet) com NAT e ponte para VMs

tag-icon • tag-icon linux routing kvm-virtualization nat bridge
Roteamento Linux com duas NICs (LAN vs Internet) com NAT e ponte para VMs

Minha configuração:

Há apenas uma máquina física nesta configuração, um sistema host para máquinas virtuais (VMs) com dois adaptadores de rede.

Uma NIC (eth0) está conectada a uma rede interna (sub-rede LAN, por exemplo, 10.xxx/24) e deve ser usada para tráfego interno.

A outra NIC (eth1) está conectada à Internet pública (possui um IP público roteável configurado). Esta conexão deve ser usada para encaminhar o tráfego de Internet pública para IPs internos das VMs (tráfego de entrada) e para permitir que as VMs acessem a Internet pública (tráfego de saída) via NAT.

Máquinas virtuais usam endereços IP na sub-rede LAN (10.xxx/24, igual a eth0)

Eu tenho um dispositivo bridge (br0) configurado para interfaces de rede virtuais das VMs (vnet0, vnet1, ...) e LAN-NIC (eth0). Que significa:

  • br0 tem um endereço IP na sub-rede LAN (10.xxx/24)
  • eth0 é adicionado à ponte
  • vnet0, vnet1, ... (usados ​​pelas VMs) são adicionados dinamicamente à ponte

Problemas

A comunicação dentro da LAN funciona bem. Além disso, o VM-Host pode ser acessado através do IP público e tem acesso à Internet.

Meu problema é a configuração do NAT para permitir que as VMs também acessem a Internet pública.

Tentei usar uma regra simples (S)NAT:

iptables -t nat -I POSTROUTING -s 10.x.x.x/24 ! -d 10.x.x.x/24 -j SNAT --to-source y.y.y.102

Considerando que yyy102 é o IP público roteável da segunda NIC (eth1).

Descobri que preciso habilitar "ip_forward" e "bridge-nf-call-iptables":

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables

Caso contrário, os pacotes em ponte não serão processados ​​pelo iptables.

Agora os pacotes das VMs parecem passar pelas seguintes cadeias de iptables:

  • "FORWARD" (normal) - eu os aceito lá (-j ACCEPT, o contador sobe)
  • "PREROUTING" (nat) - eu aceito lá (política ACCEPT, contador sobe)
  • "POSTROUTING" (nat) - Correspondem à regra SNAT

Mas nem todos os pacotes parecem chegar em PRE/POSTROUTING por algum motivo que eu não consegui descobrir até agora.

No entanto, o mais interessante tcpdump -i eth0é tcpdump -i eth1mostrar que os pacotes (tentei fazer ping em um IP externo de dentro de uma VM) parecem ser enviados através da interface errada eth0 (=LAN-NIC). Até a regra NAT foi aplicada, então o endereço de origem foi alterado para o IP da outra NIC (eth1).

Questões:

Como posso configurar o sistema para gerar pacotes NAT com o IP público como endereço de origem a ser enviado pela NIC correta (eth1)?

De alguma forma, preciso adicionar eth1 à ponte (br0)? Em caso afirmativo, como atribuo o endereço IP público corretamente? Normalmente o IP precisa ser configurado no dispositivo bridge. Eu precisaria atribuir um endereço alternativo à ponte (IP público em br0:0)?

Detalhes de configuração

A configuração de roteamento no sistema host:

# ip r
default via y.y.y.126 dev eth1
10.x.x.0/24 dev br0  proto kernel  scope link  src 10.x.x.11
y.y.y.96/27 dev eth1 proto kernel  scope link  src y.y.y.102
  • IP: yyy126 é nosso roteador para internet pública.
  • IP: yyy102 é o IP público da máquina host
  • IP: 10.xx11 é o IP da LAN da máquina host
  • SUB-REDE: 10.xx0/24 é a LAN
  • SUB-REDE: yyy96/27 é a sub-rede IP pública

Configuração da placa de rede:

# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.x.x.11  netmask 255.255.255.0  broadcast 10.x.x.255
        inet6 ####::###:####:####:####  prefixlen 64  scopeid 0x20<link>
        ether ##:##:##:##:##:##  txqueuelen 0  (Ethernet)
        RX packets 2139490  bytes 243693436 (232.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29085  bytes 2398024 (2.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 ####::###:####:####:####  prefixlen 64  scopeid 0x20<link>
        ether ##:##:##:##:##:##  txqueuelen 1000  (Ethernet)
        RX packets 2521995  bytes 290600491 (277.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 383089  bytes 48876399 (46.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xdfa60000-dfa7ffff

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet y.y.y.102  netmask 255.255.255.224  broadcast y.y.y.127
        inet6 ####::###:####:####:####  prefixlen 64  scopeid 0x20<link>
        ether ##:##:##:##:##:##  txqueuelen 1000  (Ethernet)
        RX packets 2681476  bytes 597532550 (569.8 MiB)
        RX errors 0  dropped 130  overruns 0  frame 0
        TX packets 187755  bytes 21894113 (20.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xdfa00000-dfa1ffff

Configuração da ponte:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.002590eb1900       no              eth0
                                                        vnet0

E regras do iptables:

# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  723  106K DROP       udp  --  *      *       y.y.y.0/24           0.0.0.0/0            udp spt:5404
  586 40052 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    5   420 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    2   458 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
    2   458 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1343  173K ACCEPT     tcp  --  *      *       10.x.x.2             0.0.0.0/0            tcp spt:3389
 1648  127K ACCEPT     tcp  --  *      *       0.0.0.0/0            10.x.x.2             tcp dpt:3389
   18  1040 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
   18  1040 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 525 packets, 84016 bytes)
 pkts bytes target     prot opt in     out     source               destination


# iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 13 packets, 1218 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 5 packets, 420 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 13 packets, 880 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 14 packets, 920 bytes)
 pkts bytes target     prot opt in     out     source               destination
    5   300 SNAT       all  --  *      *       10.x.x.0/24          !10.x.x.0/24           to:y.y.y.102

E aqui um pacote NAT capturado (ping da VM) na placa de interface LAN:

# tcpdump -i eth0
12:53:55.243350 IP y.y.y.102 > y.y.y.110: ICMP echo request, id 2, seq 5, length 40

Saída de "regra ip":

# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Responder1

  1. Verifique se suas VMs têm endereços IP em 10.xxx/24 (máscara de rede 255.255.255.0)

  2. Defina 10.xx11 (endereço IP br0) como gateway padrão de suas VMs

  3. Habilite o encaminhamento de IP no host físico

  4. Habilite o SNAT com:

    iptables -t nat -A POSTROUTING -s 10.x.x.x/24 -o eth1 -j SNAT --to y.y.y.102

Responder2

iptables -t nat -I POSTROUTING -s 10.xxx/24 ! -d 10.xxx/24 -j SNAT --to-source yyy102

isso deve ser alterado para

iptables -t nat -I POSTROUTING --out-interface eth1 -j SNAT --to-source y.y.y.102

De acordo com sua primeira regra, somente pacotes com destino até 10.xxx devem ser processados. Então, e quanto ao tráfego externo para sua rede? (fonte - de todo o mundo, o destino é o seu IP público :)

Como posso configurar o sistema para gerar pacotes NAT com o IP público como endereço de origem a ser enviado pela NIC correta (eth1)?

Leia acima. Basta alterar a regra NAT.

De alguma forma, preciso adicionar eth1 à ponte (br0)? Em caso afirmativo, como atribuo o endereço IP público corretamente? Normalmente o IP precisa ser configurado no dispositivo bridge. Eu precisaria atribuir um endereço alternativo à ponte (IP público em br0:0)?

De forma alguma, a menos que você saiba o que e por que está fazendo isso. Mantenha as interfaces internas e externas separadas. Permitir apenas roteamento.

Descrevi por você a configuração ao vivo (produção) por mais de 5 anos. Funcionando perfeitamente para 3 servidores host e 25 VMs, incluindo links de ponte sobre túneis openvpn.

Responder3

A postagem do Silvio me ajudou a fazer uma configuração semelhante funcionar. Além de sua postagem, aqui estão algumas coisas que eu também precisava fazer.

  1. Nas versões mais recentes dos kernels Linux (Redhat 7, por exemplo), você precisará habilitar o módulo bridge do kernel:

    modprobe br_netfilter

e, em seguida, para tornar essa alteração persistente nas reinicializações do servidor, adicione a mesma linha a um arquivo chamado /etc/modules-load.d/.conf

  1. Depois de habilitar o br_netfilter, tive que habilitar também as regras de encaminhamento do iptable para a(s) VM(s), por exemplo:

    iptables -I FORWARD -d 10.x.x.x/24 -j ACCEPT
iptables -I FORWARD -s 10.x.x.x/24 -j ACCEPT

  2. Em vez de SNAT, usei uma regra de mascaramento, pois só precisava de uma única rota dentro de um servidor de hospedagem.

    iptables -t nat -A POSTROUTING -s <single-local-vm-ip>/32 -d <my-destination-subnet>/24 -p tcp -j MASQUERADE --to-ports 1024-65535

informação relacionada