🌐 Atenea-x: la guerra del WiFi y el nacimiento del caos controlado
Si el primer día fue una locura controlada… el segundo directamente fue una guerra contra la física, la red y las limitaciones de Proxmox.
Porque claro, ya teníamos algo importante:
👉 Proxmox funcionando con interfaz gráfica
Pero alguien tuvo la brillante idea de pensar:
“¿Y si ahora lo hacemos funcionar por WiFi?”
📡 1. La idea imposible: Proxmox sin cable
Proxmox nunca fue pensado para trabajar con WiFi.
Está diseñado para entornos de servidor:
- Ethernet estable
- baja latencia
- redes predecibles
- nada de interfaces inalámbricas cambiantes
Pero eso, evidentemente, no nos frenó.
Porque si ya habíamos metido GUI…
¿por qué no romper un poco más el sistema?
📶 2. El gestor WiFi: la primera victoria engañosa
Instalamos un gestor WiFi completo:
- escaneo de redes (SSID)
- conexión manual
- almacenamiento de contraseñas
- gestión básica de redes
Lo típico… pero funcionando dentro de Proxmox.
Y tras una pequeña modificación crítica del sistema de red:
👉 conseguimos que Proxmox dejara de depender de Ethernet
👉 y empezara a usar el adaptador WiFi
En ese momento pensamos:
“Esto ya está ganado”
Error.
💥 3. Internet sí… máquinas virtuales no
Proxmox tenía Internet por WiFi.
Pero las máquinas virtuales… no.
El problema era brutalmente simple:
- WiFi no soporta bien modo bridge
- las VMs no recibían tráfico correctamente
- el networking virtual se rompía
Y ahí entendimos algo importante:
Proxmox no odia el WiFi… simplemente no fue diseñado para convivir con él.
Toda la idea empezó a desmoronarse.
🔌 4. Plan B: vuelta al cable
Sin demasiadas opciones, volvimos a lo clásico.
Conectamos un cable de par trenzado RJ-45 a un Ubuntu Server y lo configuramos como router intermedio.
La idea era simple:
- Ubuntu → router/NAT
- Proxmox → cliente estable por Ethernet
- VMs → internet a través del router
Funcionó.
Pero dejó una pregunta incómoda:
¿Para qué estamos metiendo GUI si al final dependemos de otro servidor?
🤔 5. La contradicción del proyecto
En ese punto apareció la reflexión clave:
- Queríamos un Proxmox portátil
- Pero dependíamos de infraestructura externa
- Queríamos simplicidad visual
- Pero añadíamos complejidad de red
Era evidente que algo no cuadraba.
Y entonces decidimos insistir una vez más en la locura.
🧠 6. Volver a lo básico: WiFi por terminal
El gestor gráfico de WiFi fue eliminado.
Demasiado inestable. Demasiados problemas.
Lo sustituimos por algo mucho más robusto:
👉 un gestor WiFi por comandos
El sistema funcionaba así:
- lee un fichero de texto
- obtiene SSID y contraseña
- conecta automáticamente al iniciar
Sin interfaces. Sin clics. Sin dependencias raras.
Y funcionó.
Además, permitía algo clave:
👉 conectar Proxmox desde cualquier sitio usando el móvil como hotspot
🔥 7. El salto mental: NAT en lugar de bridge
Aquí llegó el verdadero cambio de arquitectura.
La pregunta fue simple:
Si WiFi no soporta bridge… ¿por qué no usar NAT?
Y ahí todo encajó.
Diseñamos un sistema con:
- iptables para NAT
- red interna para VMs
- routing controlado desde el host
- DHCP interno en Proxmox
Las máquinas virtuales ya no dependían del WiFi directamente.
Dependían del propio Proxmox como gateway.
🚀 8. Resultado final: estabilidad en medio del caos
Después de horas de pruebas, errores, reinicios y ajustes:
🎉 lo conseguimos
- Proxmox funcionando en portátil
- conectado por WiFi
- VMs con acceso a Internet mediante NAT
- red interna estable
- sistema portátil real
🧩 Conclusión
Después de más de 8 horas de trabajo, llegamos a una conclusión clara:
No estábamos construyendo un sistema estándar. Estábamos construyendo un laboratorio de red portátil.
Y lo más sorprendente:
👉 funcionaba.