Cómo dar a las máquinas virtuales de Proxmox VE una dirección IP pública

El correo Configuración del servidor dedicado enviado cuando se construyó su máquina enumera todas las direcciones asignadas a ella, primero IPv4 y luego IPv6. La misma lista está en su panel de control en la página del servidor, bajo Acceso, redes y rDNS, donde cada dirección se muestra con su registro de DNS inverso.

En una instalación de Proxmox, el correo lleva una línea adicional, y es la razón por la que existe esta página: solo la primera dirección está configurada en el host. Las demás son suyas para asignarlas desde Proxmox, a sus máquinas virtuales o al propio host. Nuestro instalador configura deliberadamente una dirección y se detiene, porque un host que tuviera todas respondería por cada una de ellas y no dejaría nada para sus máquinas virtuales.

La máscara de red es siempre /24 (255.255.255.0) y la puerta de enlace es siempre el .1 del /24 en el que se encuentra esa dirección. Esa segunda parte importa más de lo que parece. Las direcciones pedidas juntas son consecutivas dentro de un /24, por lo que comparten puerta de enlace. Las direcciones añadidas a un servidor existente más tarde pueden venir de un rango diferente de los nuestros, y entonces cada una usa su propio .1 — por ejemplo, una dirección en 203.0.113.0/24 usa 203.0.113.1 incluso en una máquina cuya dirección principal está en otro rango. Ambas funcionan en el mismo puerto y en el mismo puente.

El resolvedor que configura nuestro instalador es 209.244.0.3. Usted es libre de apuntar sus máquinas virtuales a cualquier otro.

Inicie sesión por SSH como root y mire las interfaces que escribió el instalador:

ip -br addr
cat /etc/network/interfaces

Una máquina recién construida se ve así, con el nombre de su propia interfaz y su propia dirección principal en lugar de los ejemplos:

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 ya es un puente y la interfaz física ya es un puerto en él. Ese es todo el modelo en puente, por lo que el paso tres le pide que no cambie nada en el host.

Proxmox VE 9 es Debian 13 y usa ifupdown2, por lo que un cambio de configuración no necesita un reinicio. Edite /etc/network/interfaces y aplíquelo con:

ifreload -a

Si edita la red a través de la interfaz web de Proxmox en su lugar, sus cambios se preparan en /etc/network/interfaces.new hasta que presione Aplicar configuración. De cualquier forma, abra la consola del servidor desde su panel de control antes de recargar. Un error en este archivo saca la máquina de la red, y la consola es la forma de volver a entrar sin un ticket.

Esta es la que debe usar a menos que tenga una razón para no hacerlo. La máquina virtual es una máquina ordinaria en el mismo segmento que el host, habla directamente con nuestros enrutadores y nada en el host cambia en absoluto.

En la interfaz de Proxmox, dé a la máquina virtual un dispositivo de red en el puente vmbr0 y deje la dirección MAC que Proxmox generó para ella. Luego configure la dirección dentro de la máquina virtual exactamente como lo haría en cualquier servidor. Para una máquina virtual Debian o Ubuntu que use 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 una máquina virtual Ubuntu que use netplan, en /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]

Una máquina virtual Windows toma los mismos tres valores en las propiedades IPv4 del adaptador. Cualquier sistema operativo funciona, porque desde nuestro lado esto es simplemente otra máquina en la subred.

No tiene que registrar la dirección MAC de una máquina virtual con nosotros, y no limitamos cuántas puede usar su puerto. Algunas empresas de alojamiento sí lo hacen, y su documentación le dice que declare una MAC para cada máquina virtual. La nuestra no: el puerto del conmutador en el que está su servidor no tiene restricción de cantidad de MAC y la seguridad del puerto está desactivada, por lo que una MAC de máquina virtual se aprende exactamente como la del host. Probamos esto antes de publicarlo, poniendo una segunda MAC y una dirección libre en el propio puerto de cliente de un servidor del personal y alcanzándolo desde la internet pública.

Tres cosas que debe mantener correctas:

• Dé a cada máquina virtual una dirección MAC distinta. Dos máquinas virtuales compartiendo una, o una máquina virtual copiando la del host, rompe ambas.
• Use la puerta de enlace que pertenece al /24 de esa dirección, del paso uno.
• Solo configure una dirección que esté asignada a su cuenta. El puente da a una red real compartida con otras máquinas. Tomar una dirección que no es suya se lleva el tráfico de otra persona con ella.

Por la misma razón, no ejecute un servidor DHCP, un demonio de anuncios de enrutador fraudulento ni nada más que responda por el segmento en vmbr0. Si quiere servir DHCP a sus propias máquinas virtuales, use el modelo de subred privada del paso cinco, donde el puente no tiene puerto físico y no puede alcanzar a nadie más.

Use esta cuando quiera que cada paquete hacia y desde una máquina virtual pase por el host, para que el cortafuegos del host lo vea, o cuando prefiera que sus máquinas virtuales nunca aparezcan en nuestra capa 2 en absoluto. La dirección sigue siendo una pública de su cuenta; solo cambia la ruta.

La dirección pública se mueve del puente a la interfaz física, el host reenvía y responde ARP en nombre de las máquinas virtuales para las que enruta. En el 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

Añada un par up y down por cada dirección enrutada. Dentro de la máquina virtual, la dirección es un /32 y el host se alcanza mediante una ruta explícita en el enlace antes de la ruta predeterminada:

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

Dos notas sobre la estrofa del host. La línea proxy_arp es lo que hace que esto funcione aquí: nuestros enrutadores preguntan en el segmento por la dirección de la máquina virtual, y el host responde por ella. Sin esa línea, la máquina virtual está en silencio desde fuera. Y las dos líneas post-up echo son la forma documentada del propio Proxmox; si prefiere configurarlas de una vez por todas, ponga net.ipv4.ip_forward=1 y net.ipv4.conf.eno1.proxy_arp=1 en un archivo bajo /etc/sysctl.d/ en su lugar.

El enrutado le cuesta un poco de configuración en cada máquina virtual y le da un host que puede filtrar, contar y registrar todo. El puente no cuesta nada y no le da nada de eso. Ese es todo el intercambio.

Las máquinas virtuales que solo necesitan salir — agentes de compilación, trabajadores, una base de datos que nada externo debería tocar — no necesitan una dirección pública en absoluto. Póngalas en un puente sin puerto físico y deje que el host traduzca su tráfico a su propia dirección en la salida. Esto no cuesta direcciones y es la forma más barata de ejecutar muchas máquinas.

Añada un segundo puente en el host, dejando 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

Las máquinas virtuales van en vmbr1 con una dirección en ese rango, 10.10.10.1 como su puerta de enlace y el resolvedor que prefiera. Llegan a internet como su servidor; nada desde fuera las alcanza a menos que usted lo diga. Para publicar un servicio, añada una regla de reenvío junto a la regla de enmascaramiento, eligiendo un puerto que el host no esté usando él mismo:

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 este puente no tiene puerto físico, un servidor DHCP en él es perfectamente seguro y es una forma razonable de direccionar sus máquinas virtuales.

Su asignación IPv6 es un conjunto de direcciones individuales, no un prefijo delegado que pueda dividir. Están enumeradas en el mismo correo de configuración, bajo las IPv4, y se colocan una a la vez exactamente como las direcciones IPv4: una en el host si quiere que el host sea alcanzable, el resto en las máquinas virtuales. El instalador no configura ninguna de ellas.

Configure cada una con una longitud de prefijo /64, y la puerta de enlace es el prefijo seguido de ::1 — así que una dirección dentro de 2001:db8:1234::/64 usa 2001:db8:1234::1. En el host, añada una estrofa IPv6 junto al puente existente:

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

Y en una máquina virtual en puente:

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

Aplique con ifreload -a como antes. Debido a que las direcciones son individuales en lugar de un prefijo propio, no ejecute anuncios de enrutador ni reparta direcciones que no le hayan dado. Si necesita más de las que tiene, pregúntenos.

El DNS inverso es suyo para editar, en cada dirección, sin un ticket. Inicie sesión, abra la página del servidor y encuentre el panel Acceso, redes y rDNS. Cada dirección de la cuenta está enumerada allí con su registro actual y un botón Editar rDNS. Tanto IPv4 como IPv6 funcionan.

El formulario acepta un nombre de host: solo letras, dígitos, guiones y puntos, cada etiqueta entre 1 y 63 caracteres, al menos dos etiquetas, y añade el punto final por usted. Los cambios tardan unos minutos en aparecer.

Si la máquina envía correo, configure el registro inverso en la dirección desde la que realmente sale el correo — que, en el modelo de subred privada anterior, es la dirección del host en lugar de la de la máquina virtual — y cree el registro directo coincidente en su propio proveedor de DNS. Los servidores de correo receptores comprueban que ambos coincidan.