Como dar Proxmox VE um endereço IP público às máquinas virtuais

O e-mail Configuração do Servidor Dedicado enviado quando a sua máquina foi criada lista todos os endereços atribuídos a ela, primeiro IPv4 e depois IPv6. A mesma lista está no seu painel de controlo, na página do servidor, em Acesso, Rede e rDNS, onde cada endereço aparece com o seu registo de DNS reverso.

Numa instalação Proxmox, o e-mail traz uma linha extra, e é a razão de esta página existir: apenas o primeiro endereço é configurado no host. Os outros são seus para atribuir a partir do Proxmox, às suas máquinas virtuais ou ao próprio host. O nosso instalador configura deliberadamente um endereço e para, porque um host com todos eles responderia por cada um e não deixaria nada para as suas máquinas virtuais.

A máscara de rede é sempre /24 (255.255.255.0) e o gateway é sempre o .1 do /24 em que o próprio endereço se encontra. Esta segunda parte importa mais do que parece. Endereços pedidos em conjunto são consecutivos dentro de um /24, por isso partilham o gateway. Endereços adicionados mais tarde a um servidor existente podem vir de um intervalo diferente dos nossos, e nesse caso cada um usa o seu próprio .1 — por exemplo, um endereço em 203.0.113.0/24 usa 203.0.113.1 mesmo numa máquina cujo endereço principal está noutro intervalo. Ambos funcionam na mesma porta e na mesma bridge.

O resolvedor que o nosso instalador configura é 209.244.0.3. Pode apontar as suas máquinas virtuais para qualquer outro.

Inicie sessão por SSH como root e veja as interfaces que o instalador escreveu:

ip -br addr
cat /etc/network/interfaces

Uma máquina acabada de instalar tem este aspeto, com o nome da sua interface e o seu endereço principal no lugar dos exemplos:

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

vmbr0 já é uma bridge e a interface física já é uma porta nela. É todo o modelo em bridge, e é por isso que o passo três pede que não altere nada no host.

O Proxmox VE 9 é Debian 13 e usa ifupdown2, por isso uma alteração de configuração não precisa de reinício. Edite /etc/network/interfaces e aplique com:

ifreload -a

Se editar a rede pela interface web do Proxmox, as alterações ficam em /etc/network/interfaces.new até premir Aplicar Configuração. De qualquer forma, abra a consola do servidor no painel de controlo antes de recarregar. Um erro neste ficheiro tira a máquina da rede, e a consola é a forma de voltar a entrar sem abrir um ticket.

Use esta opção a menos que tenha uma razão para não o fazer. A máquina virtual é uma máquina comum no mesmo segmento que o host, fala diretamente com os nossos routers e nada muda no host.

Na interface do Proxmox, dê à máquina virtual um dispositivo de rede na bridge vmbr0 e deixe o endereço MAC que o Proxmox gerou para ela. Depois configure o endereço dentro da máquina virtual exatamente como faria em qualquer servidor. Para uma máquina virtual Debian ou Ubuntu com ifupdown:

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 203.0.113.58/24
    gateway 203.0.113.1
    dns-nameservers 209.244.0.3 1.1.1.1

Para uma máquina virtual Ubuntu com netplan, em /etc/netplan/01-netcfg.yaml:

network:
  version: 2
  ethernets:
    ens18:
      addresses: [203.0.113.58/24]
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses: [209.244.0.3, 1.1.1.1]

Uma máquina virtual Windows recebe os mesmos três valores nas propriedades IPv4 do adaptador. Qualquer sistema operativo funciona, porque do nosso lado isto é simplesmente outra máquina na sub-rede.

Não precisa de registar o endereço MAC de uma máquina virtual connosco, e não limitamos quantos a sua porta pode usar. Algumas empresas de alojamento fazem-no, e a documentação delas diz para declarar um MAC para cada máquina virtual. A nossa não: a porta do switch onde o seu servidor está ligado não tem restrição de contagem de MAC e a segurança da porta está desligada, por isso um MAC de máquina virtual é aprendido exatamente como o do host. Testámos isto antes de publicar, colocando um segundo MAC e um endereço livre na porta de cliente de um servidor da equipa e alcançando-o a partir da internet pública.

Três coisas a manter corretas:

• Dê a cada máquina virtual um endereço MAC distinto. Duas máquinas virtuais a partilhar um, ou uma a copiar o do host, estragam ambas.
• Use o gateway que pertence ao /24 do próprio endereço, do passo um.
• Configure apenas um endereço que esteja atribuído à sua conta. A bridge está virada para uma rede real partilhada com outras máquinas. Usar um endereço que não é seu leva consigo o tráfego de outra pessoa.

Pela mesma razão, não execute um servidor DHCP, um daemon de anúncio de router desonesto ou qualquer outra coisa que responda pelo segmento em vmbr0. Se quiser servir DHCP às suas próprias máquinas virtuais, use o modelo de sub-rede privada do passo cinco, onde a bridge não tem porta física e não consegue alcançar mais ninguém.

Use esta opção quando quiser que todos os pacotes de e para uma máquina virtual passem pelo host, para que a firewall do host os veja, ou quando preferir que as suas máquinas virtuais nunca apareçam na nossa camada 2. O endereço continua a ser um endereço público da sua conta; só o caminho muda.

O endereço público sai da bridge e vai para a interface física, o host encaminha e responde a ARP em nome das máquinas virtuais para as quais encaminha. No host:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up echo 1 > /proc/sys/net/ipv4/conf/eno1/proxy_arp

auto vmbr0
iface vmbr0 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    up ip route add 203.0.113.58/32 dev vmbr0
    down ip route del 203.0.113.58/32 dev vmbr0

Adicione um par up e down por cada endereço roteado. Dentro da máquina virtual, o endereço é um /32 e o host é alcançado por uma rota on-link explícita antes da rota predefinida:

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 203.0.113.58/32
    post-up ip route add 203.0.113.10 dev ens18
    post-up ip route add default via 203.0.113.10
    dns-nameservers 209.244.0.3 1.1.1.1

Duas notas sobre a estrofe do host. A linha proxy_arp é o que faz isto funcionar aqui: os nossos routers perguntam no segmento pelo endereço da máquina virtual, e o host responde por ela. Sem essa linha, a máquina virtual fica silenciosa do exterior. E as duas linhas post-up echo são a forma documentada do próprio Proxmox; se preferir defini-las de uma vez por todas, coloque net.ipv4.ip_forward=1 e net.ipv4.conf.eno1.proxy_arp=1 num ficheiro em /etc/sysctl.d/.

O roteamento custa-lhe um pouco de configuração em cada máquina virtual e dá-lhe um host que pode filtrar, contar e registar tudo. A bridge não custa nada e não lhe dá nenhum dos dois. É toda a troca.

Máquinas virtuais que só precisam de sair — agentes de compilação, workers, uma base de dados que nada de fora deve tocar — não precisam de endereço público. Coloque-as numa bridge sem porta física e deixe o host traduzir o tráfego delas para o seu próprio endereço à saída. Isto não gasta endereços e é a forma mais barata de gerir muitas máquinas.

Adicione uma segunda bridge no host, deixando vmbr0 como está:

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

As máquinas virtuais ficam em vmbr1 com um endereço nesse intervalo, 10.10.10.1 como gateway e o resolvedor que preferir. Chegam à internet como o seu servidor; nada de fora as alcança a menos que o diga. Para publicar um serviço, adicione uma regra de encaminhamento ao lado da regra de masquerade, escolhendo uma porta que o host não esteja a usar:

post-up iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443
post-down iptables -t nat -D PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443

Como esta bridge não tem porta física, um servidor DHCP nela é perfeitamente seguro e é uma forma razoável de endereçar as suas máquinas virtuais.

A sua atribuição de IPv6 é um conjunto de endereços individuais, não um prefixo delegado que possa dividir. Estão listados no mesmo e-mail de configuração, por baixo dos IPv4, e são colocados um de cada vez exatamente como os endereços IPv4: um no host se quiser o host alcançável, o resto nas máquinas virtuais. O instalador não configura nenhum deles.

Configure cada um com um comprimento de prefixo /64, e o gateway é o prefixo seguido de ::1 — por isso um endereço dentro de 2001:db8:1234::/64 usa 2001:db8:1234::1. No host, adicione uma estrofe IPv6 ao lado da bridge existente:

iface vmbr0 inet6 static
    address 2001:db8:1234::2/64
    gateway 2001:db8:1234::1

E numa máquina virtual em bridge:

iface ens18 inet6 static
    address 2001:db8:1234::5/64
    gateway 2001:db8:1234::1

Aplique com ifreload -a como antes. Como os endereços são individuais e não um prefixo seu, não execute anúncios de router nem distribua endereços que não lhe foram dados. Se precisar de mais do que tem, pergunte-nos.

O DNS reverso é seu para editar, em todos os endereços, sem abrir um ticket. Inicie sessão, abra a página do servidor e encontre o painel Acesso, Rede e rDNS. Todos os endereços da conta estão listados lá com o registo atual e um botão Editar rDNS. IPv4 e IPv6 funcionam ambos.

O formulário aceita um nome de host: apenas letras, dígitos, hífenes e pontos, cada etiqueta entre 1 e 63 caracteres, pelo menos duas etiquetas, e adiciona o ponto final por si. As alterações demoram alguns minutos a aparecer.

Se a máquina enviar correio, defina o registo reverso no endereço de onde o correio realmente sai — que, no modelo de sub-rede privada acima, é o endereço do host e não o da máquina virtual — e crie o registo direto correspondente no seu próprio fornecedor de DNS. Os servidores que recebem correio verificam que os dois coincidem.