Determinado a transformar um computador antigo em um servidor (NAS, Home Assistant, ...), decidi aprender sobre Virtualização com o Projeto Xen no Debian. O servidor deve ser usado somente em LAN e tem o endereço IP estático 10.56.0.191. Estou tentando criar um convidado em 10.56.0.192 com Xen. Para isso, segui as informações fornecidas no guia para iniciantes do projeto Xen e consegui criar um convidado VP executando Debian também.
Infelizmente, o convidado não tem conexão nenhuma. Ainda seguindo o guia para iniciantes, junto com a rede Xen , tentei configurar a interface do host, encaminhamento de IP, proxy ARP e mascaramento de IP. Infelizmente, o wiki faz referência a iptable que parece ter sido substituído por nftables . Portanto, estou tentando usar nftables .
O convidado parece não conseguir se comunicar (conexão testada por ping em vários hosts na LAN), enquanto o host consegue se comunicar corretamente.
Parece que estou esquecendo de algo importante, mas não consigo descobrir. Você poderia me ajudar com esse problema?
Configurei o host e o convidado da seguinte maneira.
Agradeço sua ajuda :-)
No host
Criei uma ponte, xenbr0, da /etc/network/interfacesseguinte forma:
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# Static IP on ethernet
iface enp2s0 inet manual
# Bridge for Xen hypervisor
auto xenbr0
iface xenbr0 inet static
address 10.56.0.191
netmask 255.255.0.0
gateway 10.56.0.1
dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8
bridge_ports enp2s0
bridge_stp off
bridge_maxwait 0
bridge_fd 0
O encaminhamento IPv4 e o proxy ARP estão habilitados em /etc/sysctl.conf.
net.ipv4.ip_forward=1
net.ipv4.conf.enp2s0.proxy_arp=1
Com nftables , criei uma tabela nat e uma cadeia postrouting . Depois adicionei uma regra para o mascaramento de IP.
nft add table nat
nft add chain ip nat postrouting { type nat hook postrouting priority 0 \; }
nft add rule nat postrouting ip saddr 10.56.0.0/16 oif enp2s0 masquerade
A chamada nft list rulesetretorna o seguinte:
table ip nat {
chain postrouting {
type nat hook postrouting priority filter; policy accept;
ip saddr 10.56.0.0/16 oif "enp2s0" masquerade
}
}
No convidado
No arquivo de configuração do convidado, a interface virtual é definida comovif = [ 'ip=10.56.0.192 ,mac=00:16:3E:FA:9C:76, bridge=xenbr0' ]
Também estou tentando configurar sua interface de rede definindo um IP estático em /etc/network/interfaces:
auto lo
iface lo inet loopback
auto enX0
iface enX0 inet static
address 10.56.0.192
gateway 10.56.0.1
netmask 255.255.0.0
dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8
Se o VIF que representa o convidado da VM estiver na ponte, o NAT no host da VM será irrelevante, pois ele se comunica diretamente pela ponte e nem mesmo usa o host como um gateway.
Mas pelos comentários, parece que o Xen não coloca o VIF na ponte como deveria. Faça isso manualmente usando
ip link set <vif_name> master xenbr0.Meu palpite é que o Xen ignora toda a sua
vif =configuração por causa doip=parâmetro que não deveria estar lá – não consegui encontrá-lo na documentação e, de fato, nem faz sentido queip=exista porque o hipervisor só tem controle sobre o endereço MAC do convidado (que é um hardware emulado), mas não sobre o endereço IP do convidado (que é algo que o convidado decide no software).Resposta inicial escrita na semana passada:
A configuração que você tem é uma mistura de várias configurações contraditórias. Em particular, você tem uma mistura de configuração "em ponte" e "roteada":
Se enp2s0 fizer parte da ponte, então efetivamente a VM estará conectada diretamente à mesma LAN que o host (no nível Ethernet) – ela se comunicará diretamente com o gateway LAN físico em 10.56.0.1, e assim por diante.
Mas se a VM estiver configurada para usar 10.56.0.1 como seu gateway (pegando o atalho pela ponte)... isso significa que ela não usará 10.56.0.191 (o PC host) como seu gateway e, portanto, seu tráfego não passará pelo processamento de IP do host, incluindo quaisquer regras de NAT do nftables.
Não que o NAT seria necessário, de qualquer forma – tanto o NAT quanto o proxy-ARP também seriam completamente desnecessários nessa configuração. O proxy-ARP é redundante porque a ponte já encaminha as solicitações/respostas ARP reais diretamente para a VM, então não há necessidade de o host responder em seu nome; o NAT é redundante porque ambos os endereços estão dentro da mesma sub-rede, então o gateway já conhece uma rota para o endereço real da VM de qualquer maneira (novamente, diretamente pela ponte).
Então, se você quiser uma configuração em ponte onde a VM é um membro completo da LAN física, a primeira coisa a fazer seria desabilitar o proxy-ARP novamente e certificar-se de que o roteador físico aprenda corretamente o endereço MAC real da VM (geralmente as entradas de cache ARP expiram após um curto período). A segunda coisa – se você estiver fazendo isso em alguma LAN corporativa – seria entrar em contato com quem gerencia a rede.
Por outro lado, se uma configuração roteada com NAT for desejada (para esconder a existência da VM da LAN física), então enp2s0 não deve fazer parte da ponte. Em vez disso, enp2s0 e xenbr0 devem ser duas interfaces separadas com configurações de IP separadas – e, mais importante, com sub-redes de IP não sobrepostas.
Por exemplo, como a LAN usa 10.56.0.0/16, você pode usar 192.168.44.0/24 para sua rede Xen, e a VM seria configurada para usar o host (por exemplo, 192.168.44.1) como seu gateway.
Como o roteamento é implícito, ele também precisa ser habilitado em todo o sistema via /etc/sysctl.conf no sistema host (
net.ipv4.conf.all.forwarding=1).(Tecnicamente falando, se a ponte contiver apenas esta única VM, então a ponte como um todo é redundante; o roteamento pode ser feito diretamente entre enp2s0 e a interface individual que representa a VM. Ainda assim, usar uma ponte torna várias outras coisas mais convenientes.)