Ya hemos defendido la estrategia: dividir la red en zonas que no se fían entre sí para contener el movimiento lateral. Pero una estrategia sin ejecución es un PowerPoint. En algún momento hay que sentarse a escribir las reglas concretas, y ahí aparecen las preguntas prácticas que ningún diagrama responde: ¿en qué orden se evalúan? ¿la regla va en «entrada» o en «salida»? ¿cómo evito repetir la misma regla en cuarenta VMs? ¿y cómo hago que una subred privada salga a Internet, o que un servicio interno sea accesible desde fuera?
Este artículo es el manual de campo. Baja al detalle del firewall de Proxmox —cómo se evalúan las reglas de verdad— y del NAT del SDN, que a pesar de todo lo que dijimos sobre que «NAT ya no es gratis» sigue siendo una herramienta necesaria en redes IPv4 internas. No es contradictorio: defender IPv6 para el futuro y saber hacer NAT hoy son dos cosas compatibles.
Lo primero que hay que interiorizar: el firewall de Proxmox no es una lista mágica que «entiende lo que quieres». Es un motor con reglas claras, y si no las conoces, tus reglas hacen cosas raras.
Se organiza en niveles que se combinan. Datacenter (todo el clúster), host (cada nodo) y VM/contenedor (cada máquina). Una VM está sujeta a las reglas de su nivel más las que apliquen por encima. La microsegmentación vive sobre todo en el nivel de VM: cada máquina, su política.
Se evalúa por dirección. Cada regla es de entrada (IN, tráfico que llega a la máquina) o de salida (OUT, tráfico que sale de ella). Esto confunde al principio: para permitir que una web reciba peticiones, la regla va en IN sobre la VM web; para permitir que esa web hable con la base de datos, va en OUT sobre la web (o en IN sobre la base de datos). Pensar en la dirección desde el punto de vista de cada máquina es la mitad del oficio.
Se evalúa en orden, y gana la primera coincidencia. Las reglas se recorren de arriba abajo; la primera que coincide con el tráfico decide, y no se miran las siguientes. Esto tiene una consecuencia práctica enorme: el orden de las reglas cambia el comportamiento. Una regla de «denegar todo» puesta arriba bloquea reglas de «permitir» que estén debajo. La disciplina correcta: las excepciones específicas (permitir) arriba, las políticas generales (denegar) abajo.
La política por defecto manda. Se define qué pasa con el tráfico que no coincide con ninguna regla. La política sólida es IN a DROP por defecto (denegar entrante salvo lo permitido explícitamente) y OUT más permisivo o también controlado según cuánto quieras cerrar. Es el «denegar por defecto» llevado a la configuración.
Escribir reglas VM a VM se vuelve inmanejable rápido. Proxmox da tres herramientas para no repetirte, y usarlas bien es la diferencia entre un firewall que se mantiene y uno que nadie se atreve a tocar.
La regla de oro de mantenibilidad: si vas a escribir la misma IP o la misma regla dos veces, para y usa un IPSet o un Security Group. El firewall que se puede mantener seis meses después es el que está construido con estas piezas, no con cientos de reglas sueltas.
Un firewall que bloquea en silencio es un infierno de depurar. Cuando algo «no conecta y no sé por qué», la respuesta suele estar en si el firewall lo está tirando. Proxmox permite activar el log por regla y por nivel, registrando qué tráfico se acepta y cuál se descarta. La práctica recomendada al montar o cambiar reglas: activa el log en la política de descarte mientras validas, mira qué se está bloqueando, ajusta, y baja el nivel de log cuando esté estable. La mayoría de los «no me funciona el firewall» se resuelven mirando el log dos minutos.
Aquí entramos en el terreno que parece contradecir nuestro discurso pro-IPv6. No lo es. Mientras trabajes con redes IPv4 internas —la realidad de casi todo el mundo hoy—, el NAT sigue siendo una herramienta necesaria, y el SDN de Proxmox lo hace. Hay dos usos, opuestos en dirección:
Tienes una red SDN interna con direcciones privadas (10.x) donde viven tus VMs, y quieres que puedan salir a Internet —actualizarse, llamar a APIs— sin darles a cada una una IP pública. El SNAT (Source NAT) traduce la dirección privada de origen por la pública del nodo al salir. Es el NAT «de salida» de toda la vida. En una zona SDN de tipo adecuado, Proxmox lo configura para que la subred entera comparta la salida por la IP del host. Es cómodo y, para tráfico saliente interno, perfectamente razonable.
El caso inverso: una VM en una red privada aloja un servicio que quieres accesible desde fuera. El DNAT (Destination NAT), o redirección de puertos, hace que las peticiones que llegan a un puerto de la IP pública del nodo se reenvíen a la IP privada y puerto de la VM interna. Es el «port forwarding» clásico: el puerto 443 público → la VM web interna en su 443.
Aquí conviene el matiz honesto que ya defendimos: cada regla de DNAT es una de esas «capas ocultas» que complican el diagnóstico de las que hablábamos en el post de NAT. Funcionan, son legítimas, pero cada redirección es un sitio más donde una conexión se puede perder. Por eso: úsalas cuando hagan falta, documéntalas, y ten presente que en un mundo IPv6 muchas desaparecerían porque la VM tendría dirección propia enrutable. NAT hoy, sí; NAT como forma de vida, no.
Reuniendo firewall y NAT, un esquema práctico para una zona típica:
IN a DROP. Nada entra salvo lo permitido.admin-ips (tu red de administración) hacia los puertos de gestión. Excepción específica, arriba.IN desde la zona de aplicación, nunca desde la pública. (Ver microsegmentación.)Con esto tienes la estrategia (zonas que no se fían) ejecutada en reglas concretas, mantenibles y depurables. Que es donde la seguridad de red deja de ser un diagrama y empieza a proteger de verdad.
¿En qué orden se evalúan las reglas del firewall de Proxmox? De arriba abajo, por dirección (entrada o salida), y gana la primera regla que coincide con el tráfico. El resto no se miran. Por eso el orden importa: las excepciones específicas (permitir) van arriba y las políticas generales (denegar) abajo. Una regla de «denegar todo» colocada arriba anula los «permitir» que tenga debajo.
¿Una regla va en entrada o en salida?
Depende del punto de vista de la máquina. Para que una VM reciba tráfico (una web en el 443), la regla va en entrada (IN) sobre esa VM. Para que una VM inicie una conexión (la web hablando con la base de datos), va en salida (OUT) sobre ella. Pensar la dirección desde cada máquina es clave.
¿Para qué sirven los Security Groups y los IPSets? Para no repetir reglas. Un Security Group es un conjunto de reglas con nombre que aplicas a muchas VMs a la vez (cambias el grupo, cambian todas). Un IPSet es un grupo de IPs con nombre; escribes las reglas contra el nombre y actualizas las IPs en un solo sitio. Son lo que hace un firewall mantenible a escala.
¿Proxmox puede hacer NAT? Sí, a través de su SDN. SNAT (NAT de salida) para que una subred privada salga a Internet compartiendo la IP del nodo, y DNAT (redirección de puertos) para publicar un servicio interno hacia fuera. Son herramientas legítimas en redes IPv4; con IPv6 muchas dejarían de hacer falta porque cada VM tendría dirección enrutable propia.
¿No dijisteis que el NAT es un problema? Dijimos que el NAT tiene costes ocultos y que IPv6 lo reduce estructuralmente, no que no haya que usarlo nunca. En redes IPv4 internas —la realidad de hoy— el NAT es necesario y correcto. La postura es: úsalo a conciencia y documentado, no como forma de vida por defecto, y camina hacia IPv6 donde puedas.
¿Tienes clara la estrategia de segmentación pero se te atraganta escribir las reglas y el NAT en Proxmox? Te ayudamos a montar el firewall y el SDN de tu cloud privado: reglas mantenibles, NAT donde toca y todo documentado. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.
Ceder unas horas de una GPU suele significar crear un usuario, repartir claves SSH, revisar permisos y acordarse de retirarlo todo después. RunSnack reduce eso a ejecutar un script y pasar un enlace que abre una terminal en el navegador, dentro de un contenedor Docker con acceso a la GPU del anfitrión. Es una idea buena y pequeña, con una frontera de seguridad que su propio autor documenta sin adornos: repasamos qué resuelve, qué no, y cuándo la respuesta correcta sigue siendo una máquina virtual.
Proxmox VE deja crear snapshots desde cualquier sitio, pero no hay una vista de todos los del clúster. ProxSnap, escrito en Rust por el autor de ProxLB, lista, filtra por fecha y borra snapshots viejos desde la API. Qué hace de verdad, qué cuesta un snapshot olvidado según el almacenamiento, y cómo montar una política sin llevarte por delante algo que hacía falta.