Cuando le entregaron su servidor, se configuró una dirección IPv4 en él y el resto se dejó tal cual. Es algo deliberado, y esta página le explica cómo terminar el trabajo. Hay tres maneras de hacerlo y ninguna lleva mucho tiempo: poner la máquina directamente en la red con su propia dirección, enviar su tráfico a través del host, u ocultar todo un conjunto de máquinas detrás de la dirección que ya tiene. Probamos las tres en nuestra propia red antes de escribir esto.
Lea los dos primeros. Después, los pasos tres, cuatro y cinco son alternativas — elija el que coincida con lo que está montando.
Busque el correo titulado Configuración del servidor dedicado, enviado el día en que se creó la máquina. Enumera todo lo asignado al servidor: primero las direcciones IPv4 y luego cualquier IPv6. La misma lista está en su cuenta, en la página del servidor, en el panel titulado Acceso, redes y rDNS.
En un servidor Proxmox, ese correo añade una línea debajo de la lista que le indica que al host se le ha dado solo la primera dirección y que las restantes son suyas para repartir — a máquinas virtuales, o también al host si quiere que tenga más de una. Configuramos una sola dirección para que la máquina arranque accesible y luego nos detenemos. Si las configura todas en el host, este responderá por todas ellas y sus máquinas virtuales no tendrán nada que reclamar.
Dos números importan cada vez que escriba una dirección. La máscara de red es /24, es decir, 255.255.255.0. La puerta de enlace es el propio rango de esa dirección, terminado en .1 — así, una dirección en 203.0.113.0/24 usa 203.0.113.1. Las direcciones emitidas juntas están una al lado de la otra y comparten una puerta de enlace. Las direcciones añadidas a un servidor meses después pueden venir de un rango distinto nuestro, y entonces usan su propio .1. Equivocarse en esto es la razón más común por la que una máquina virtual nueva no puede alcanzar nada, y le cuesta a la gente una tarde entera.
Para DNS configuramos 209.244.0.3 en el host. Apunte sus máquinas virtuales a donde prefiera.
Inicie sesión por SSH como root y eche un vistazo:
ip -br addr cat /etc/network/interfaces
En una máquina que acabamos de crear, ese archivo se lee más o menos así, con el nombre de su interfaz y su propia primera dirección en lugar de las mostradas:
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 Lo útil de notar es que vmbr0 ya es un puente y la tarjeta de red ya está conectada a él. No se necesita nada más para el paso tres, razón por la cual el paso tres le pide no cambiar nada aquí.
Proxmox VE 9 se asienta sobre Debian 13 y usa ifupdown2, de modo que los cambios de red surten efecto sin reiniciar la máquina. Guarde el archivo y ejecute:
ifreload -a
Si edita a través de la interfaz web de Proxmox, sus cambios se escriben en /etc/network/interfaces.new y se retienen hasta que pulse Aplicar configuración. Sea cual sea el método, abra primero la consola desde su cuenta. Un error tipográfico en este archivo y la máquina se cae de la red; la consola entra por otra vía y seguirá funcionando.
Empiece aquí. Su máquina virtual se comporta como un ordenador separado enchufado al mismo conmutador, habla con nuestros enrutadores por sí misma y el host no necesita ningún cambio en absoluto.
En Proxmox, añada un dispositivo de red a la máquina, establezca el puente en vmbr0 y deje la dirección MAC que Proxmox rellenó. Luego configure la dirección dentro de la máquina. Debian o Ubuntu con la configuración clásica:
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 Ubuntu con 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] En Windows, los mismos tres valores van en la configuración IPv4 del adaptador. Realmente no importa qué ejecute la máquina; para nosotros es un ordenador más en el cable.
No hay nada que avisarnos primero. No tiene que enviarnos la dirección MAC de cada máquina virtual, y no limitamos cuántas puede usar su puerto. Varias empresas de alojamiento sí lo hacen, y sus instrucciones le hacen rellenar un formulario por cada máquina nueva. Lo comprobamos en lugar de asumirlo: el puerto en el que está su servidor no tiene límite de MAC establecido y la seguridad del puerto está desactivada, y antes de publicar esto pusimos una segunda dirección y MAC en el puerto propio de una máquina del personal y la alcanzamos desde la internet pública.
Tres cosas que conviene hacer bien:
• Cada máquina necesita su propia dirección MAC. Dos máquinas compartiendo una, o copiando la del host, y ninguna funciona correctamente.
• Use la puerta de enlace que pertenece al rango de esa dirección, del paso uno.
• Use solo direcciones que estén en su cuenta. Este puente da a una red real con máquinas de otras personas. Una dirección que no es suya se lleva su tráfico con ella.
Por la misma razón: nada que reparta direcciones pertenece a vmbr0. Ni servidor DHCP ni anuncios de enrutador. Si quiere repartir direcciones a sus propias máquinas automáticamente, use el paso cinco, donde el puente no tiene salida y no puede alcanzar a nadie más.
Elija esta cuando quiera que el host vea cada paquete, para que su cortafuegos pueda actuar sobre él, o cuando prefiera que sus máquinas nunca aparezcan en la red compartida. Siguen recibiendo direcciones públicas reales de su cuenta; solo cambia la ruta.
La dirección pública sale del puente y va a la tarjeta de red, se le dice al host que reenvíe y este responde en nombre de las máquinas que están detrás. 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 Una línea up y down por cada dirección que enrute de esta manera. Dentro de la máquina la dirección es una /32, y hay que llegar al host mediante una ruta explícita antes de la 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 No omita la línea proxy_arp. Nuestros enrutadores preguntan a la red quién tiene cada dirección, y esa línea es lo que hace que el host responda por las máquinas que están detrás. Si la deja fuera, simplemente son invisibles. Las dos líneas post-up echo son la manera propia de Proxmox de escribirlo. Para establecerlas de forma permanente, deje caer un archivo en /etc/sysctl.d/ que contenga:
net.ipv4.ip_forward=1 net.ipv4.conf.eno1.proxy_arp=1
Lo que compra con el trabajo extra es un host que puede filtrar y registrar cada paquete. Si no lo necesita, el paso tres tiene menos cosas que pueden salir mal.
Muchas máquinas solo inician conversaciones: ejecutores de compilación, trabajadores de colas, una base de datos que nada externo debería tocar. Deles a esas una dirección privada en un puente sin salida propia y deje que el host traduzca su tráfico a su dirección al pasar. No usa nada de su asignación, así que puede ejecutar tantas como el hardware soporte.
Añada un segundo puente, dejando vmbr0 exactamente 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 Ponga las máquinas en vmbr1, dé a cada una una dirección en ese rango con 10.10.10.1 como puerta de enlace, y ya están en marcha. Para el resto de internet parecen su servidor. Nada las alcanza desde fuera a menos que lo pida, y pedirlo es una regla más junto a la primera, en un puerto que el host no esté usando ya:
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
Este puente no tiene puerto físico, así que un servidor DHCP en él es seguro y es una manera ordenada de asignar direcciones a las máquinas que están detrás.
Lo que tiene es un puñado de direcciones IPv6 separadas, no un bloque para dividir. Están al final del mismo correo de configuración, y se colocan una a una exactamente igual que las IPv4: una en el host si quiere que el host sea accesible por IPv6, las demás en las máquinas que las necesiten. El instalador no configura ninguna, así que todo esto es suyo para añadir.
Escriba cada una con un /64 al final, y la puerta de enlace es el prefijo con ::1 después — una dirección dentro de 2001:db8:1234::/64 usa 2001:db8:1234::1. En el host, junto al puente que ya está allí:
iface vmbr0 inet6 static
address 2001:db8:1234::2/64
gateway 2001:db8:1234::1 Y en una máquina en el puente:
iface ens18 inet6 static
address 2001:db8:1234::5/64
gateway 2001:db8:1234::1 Luego ifreload -a, como antes. Como se trata de direcciones individuales y no de un bloque propio, no anuncie rutas ni reparta direcciones que no le hayan dado. ¿Le falta alguna? Pídanosla.
Usted mismo configura el DNS inverso, en cualquier dirección, sin preguntar a nadie. Inicie sesión, abra el servidor y busque el panel titulado Acceso, redes y rDNS. Cada dirección aparece listada con el nombre al que responde actualmente y un botón Editar rDNS al lado. Las direcciones IPv6 funcionan igual.
El cuadro pide un nombre de host: letras, números, guiones y puntos, cada parte entre 1 y 63 caracteres, al menos dos partes, y el punto final se añade por usted. Déle unos minutos para que surta efecto.
Si la máquina envía correo, la dirección a nombrar es aquella desde la que realmente sale el correo — con el paso cinco es la dirección del host, no la de la máquina — y también querrá el registro directo correspondiente en su proveedor de DNS. Los servidores de correo del otro extremo comprueban que ambos coincidan y rechazan el correo cuando no lo hacen.
Lo que nos pregunta la gente después de seguir esta página.