Linha de comando KVM nat

Question 1

A ideia comum do NAT é que vocênão vemosendereços traduzidos. Você não tem rotas para eles. Eles não existem para você. Você vê apenas os endereços para os quais eles estão traduzidos.

O caso do QEMU não é nada diferente. Neste caso, seu host está "fora", sua VM está "dentro", então a VM nunca poderá ser acessada pelo endereço ao qual está atribuída. Você tem o endereço 10.0.2.2/24 da VM, mas quando chega à Internet, seus pacotes são traduzidos para 192.168.1.172pelo processo QEMU, então o host considera esses pacotes como criados pelo processo QEMU e os trata como quaisquer outros pacotes, digamos, de um navegador da Web executado localmente ou algo parecido.

Como acessar uma VM do host? Quando temos NAT, para alcançar hosts ocultos atrás dele, instalamosDNATregras. E novamente, o caso do QEMU não é diferente, você deve configurar algumas regras nele, e então você pode se comunicar com a VM a partir do host (ou de outros hosts, se desejar) enviando pacotes para portas selecionadas dohospedarendereço.

De acordo comDocumentação do QEMU, para configurar regras de DNAT em seu NAT de modo de usuário, você usa a hostfwdcláusula. Vamos introduzir o seguinte em sua linha de comando:

    -netdev user,id=usernet0,hostfwd=tcp::11111-:22 \
    -device virtio-net-pci,netdev=usernet0,mac=08:00:27:92:B0:51

Então, a porta tcp 11111 será ocupada pelo qemu-system-x86_64processo na minha máquina, e se você conectar aohost localporta 11111, a conexão será feita na porta 22 da VM.

A forma geral é hostfwd=hostip:hostport-guestip:guestport, mas se você omitir hostip, será localhost e, se omitir guestip, será o primeiro endereço "não gateway" dentro da rede convidada.

Notei que você foi mencionado virsh. Estás a correr libvirt? Então a pergunta é duplicada; Ver comentários.

Answer

A ideia comum do NAT é que vocênão vemosendereços traduzidos. Você não tem rotas para eles. Eles não existem para você. Você vê apenas os endereços para os quais eles estão traduzidos.

O caso do QEMU não é nada diferente. Neste caso, seu host está "fora", sua VM está "dentro", então a VM nunca poderá ser acessada pelo endereço ao qual está atribuída. Você tem o endereço 10.0.2.2/24 da VM, mas quando chega à Internet, seus pacotes são traduzidos para 192.168.1.172pelo processo QEMU, então o host considera esses pacotes como criados pelo processo QEMU e os trata como quaisquer outros pacotes, digamos, de um navegador da Web executado localmente ou algo parecido.

Como acessar uma VM do host? Quando temos NAT, para alcançar hosts ocultos atrás dele, instalamosDNATregras. E novamente, o caso do QEMU não é diferente, você deve configurar algumas regras nele, e então você pode se comunicar com a VM a partir do host (ou de outros hosts, se desejar) enviando pacotes para portas selecionadas dohospedarendereço.

De acordo comDocumentação do QEMU, para configurar regras de DNAT em seu NAT de modo de usuário, você usa a hostfwdcláusula. Vamos introduzir o seguinte em sua linha de comando:

    -netdev user,id=usernet0,hostfwd=tcp::11111-:22 \
    -device virtio-net-pci,netdev=usernet0,mac=08:00:27:92:B0:51

Então, a porta tcp 11111 será ocupada pelo qemu-system-x86_64processo na minha máquina, e se você conectar aohost localporta 11111, a conexão será feita na porta 22 da VM.

A forma geral é hostfwd=hostip:hostport-guestip:guestport, mas se você omitir hostip, será localhost e, se omitir guestip, será o primeiro endereço "não gateway" dentro da rede convidada.

Notei que você foi mencionado virsh. Estás a correr libvirt? Então a pergunta é duplicada; Ver comentários.

Question 2

Você pode usar uma ponte sem escravizar nenhuma de suas interfaces Ethernet físicas no host da VM.

Digamos que optemos pela escolha da sub-rede 10.0.2.0/24(o que NÃO é necessário):

# ip l add natbr0 type bridge
# ip a add 10.0.2.1/24 dev natbr0

Em seguida, crie o seguinte arquivo:

$ echo 'allow natbr0' | sudo tee /etc/qemu/bridge.conf 
allow natbr0

Em seguida, inicie o qemu com, por exemplo, -nic bridge,br=natbr0ou -netdev bridge,br=natbr0,id=nb0 -device virtio-net,netdev=nb0, que conectará tapsua VM à ponte de maneira dinâmica (ou seja, a tapinterface será removida assim que a VM for desligada).

Você também precisará configurar o IP estático na VM:

# ip a add 10.0.2.2/24 dev ens3
# ip r add default via 10.0.2.1

A menos que você também configure um servidor DHCP (por exemplo, dnsmasq) no host. Não se esqueça de configurar o servidor DNS para usar também dentro da VM.

Observe que as VMs que fazem uso da mesma ponte podem se comunicar entre si, a menos que você bloqueie tal comunicação por algum meio (por exemplo, ebtables).

A defaultrota (e o servidor DNS a utilizar) só são necessários se quiser que a VM consiga chegar ao "exterior". Se você só precisa dele para se comunicar com o host da VM, você deve pular o segundo comando e parar de ler. (Bem, leia o P.S.)

Provavelmente seria melhor configurar, por exemplo, dnsmasq no host para ser um encaminhador de DNS se você não quiser usar um servidor DNS "público" específico na VM, embora usar DNAT para encaminhar solicitações de DNS, por exemplo, 192.168.1.1deva funcionar para os básicos .

Então você precisará ativar o encaminhamento de IP:

# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Se você quiser evitar o encaminhamento de IP de/para determinada interface de rede (por exemplo tun0) por motivos de segurança, você precisará configurar um firewall.Por exemplo:

# iptables -A FORWARD -i tun0 -j DROP
# iptables -A FORWARD -o tun0 -j DROP

Como você possui rotas de túnel (VPN) que praticamente substituem a defaultrota, o tráfego da VM para a Internet também irá para o túnel (a menos que você tenha adicionado as regras de exemplo acima). Se você quiser que o tráfego passe, por exemplo, pelo seu roteador, você precisará de roteamento de política. Por exemplo:

# ip ru add iif natbr0 lookup table 123
# ip r add 192.168.1.1 dev wlan0 table 123 # probably optional
# ip r add default via 192.168.1.1 table 123

Você também pode impedir que suas VMs alcancem seus hosts LAN:

# iptables -A FORWARD -i natbr0 -d 192.168.1.0/24 -j DROP

Faça exceções (observe o -I) se for redirecionar solicitações de DNS para o seu roteador:

# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p tcp --dport 53 -j ACCEPT
# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p udp --dport 53 -j ACCEPT

Por fim, configure o iptables para executar SNAT dinamicamente (conforme a interface de saída) para sua sub-rede VM:

# iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j MASQUERADE

Observe que isso NÃO se destina e não impedirá exatamente que certos tráfegos "externos" (seus hosts físicos da LAN ou a Internet; o host da VM não conta) possam alcançar suas VMs. Apenas interrompe a comunicação como efeito colateral quando o endereço de origem dos tráfegos de resposta das VMs é alterado antes de serem encaminhados. Para um isolamento adequado, você precisará de regras apropriadas (adicionais) na FORWARDcadeia. Considere ter uma configuração "com estado" se você precisar.

Além disso, você pode redirecionar solicitações de DNS para o host das VMs para o seu roteador:

iptables -t nat -A PREROUTING -d 10.0.2.1 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1
iptables -t nat -A PREROUTING -d 10.0.2.1 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1

O que mais ou menos permitirá que você use 10.0.2.1como servidor DNS na VM.

PS Todas as manipulações acima (exceto a criação de /write to /etc/qemu/bridge.conf) são voláteis, ou seja, elas desaparecerão assim que você reiniciar (a menos que sua distro faça algo bobo). Não vou me aprofundar em como você pode torná-los persistentes, já que existem diferentes formas/abordagens e isso pode ser específico da distribuição.

Answer