No es ningún secreto que Digi está en pleno auge y mucha gente se está pasando a sus redes. También es cierto que la infraestructura en el hogar es algo incómoda (al menos, para mí) pues te instalan ONT + router por separado (en muchos casos).
Aprovechando que tengo un ProLiant ML310e Gen8 con dos tarjetas de red desde hace algunos años, con una boca sin utilizar y en él tengo instalado proxmox, pues me puse a investigar para utilizarlo como router y dejar la infraestructura tal que ONT + Servidor. Nos ahorramos un aparato 🙂
El siguiente paso era cómo hacerlo; era obvio que teniendo proxmox me tocaría virtualizar. Pero, ¿qué solución exactamente? Estuve optando entre pfsense y opnsense. Me decanté por opnsense gracias a este artículo (en inglés) , ya que son prácticamente iguales.
Así que seguí un tutorial de instalación (en inglés) de pfsense en proxmox. Como son prácticamente iguales, se puede seguir el tutorial de pfsense para opnsense.
Agrego el USB directamente a la máquina, como se puede observar en la imagen de abajo.
Hasta aquí todo bien….O casi todo. Puedo ver que no me aparece la nueva conexión. Leyendo la documentación de freeBSD y los foros, resulta que freeBSD sólo tiene soporte para este chipset (Atheros AR9271) en modo cliente1, y no en modo AP2 por lo que la idea de usar estas soluciones quedó descartada. Probablemente se podría, pero mi conocimiento de freesBSD es nulo, por lo que me llevaría mucho tiempo.
Se me vino a la mente esa gran distribución utilizada en muchos routers SOHO3 para mejorar sus funcionalidades o para ampliarlas: OpenWrt. Está basada en linux y tiene un gran soporte de la comunidad, así como miles de paquetes instalables de manera similar a Debian/Ubuntu.
Ya tenemos candidato para probar. Ahora queda elegir si contenedor LXC o máquina virtual VM.
Al instalar virtualmin para usarlo como servidor web/mail entre otros, la configuración por defecto suele ser más que suficiente. Pero, si vemos el log de postfix, nos encontraremos un warning que nos indica que algo no está del todo bien:
warning: do not list domain example.com in BOTH mydestination and virtual_alias_domains
Aunque no es un error y el servidor de correo funcionará perfectamente a muchos nos gusta dejar un log limpio, sin errores ni warnings.
La solución está en cambiar el parámetro $myhostname dentro de mydestination en el archivo /etc/postfix/main.cf. Dicha modificación se quedaría tal que así:
Básicamente, en el parámetro mydomain hemos elegido un subdominio diferente al de myorigin. También hay que tener en cuenta que el archivo /etc/postfix/main.cf es mucho más completo. Sólamente hemos indicado cómo se quedarían los cambios realizados para que desaparezca el warning y el servidor siga funcionando correctamente.
Otras sugerencias encontradas en stackexchange y similares provocan que el servidor deje de recibir correos.
Uno de los sistemas de ficheros a tener en cuenta a la hora de montar un servidor es ZFS. Yo lo tengo montado en mi servidor en casa o, como lo llaman en reddit, homelab. De hecho, tengo montado un RAID10 con Proxmox (4 x 1TiB) con el sistema de archivos ZFS, puesto que el raid que ofrece el servidor es un fakeRAID.
A la hora de crear contenedores no sabemos el espacio que vamos a necesitar antes de crear dichos contenedores. La recomendación general es crear un volumen de unos pocos gigas e ir agrandándolo según se vaya necesitando, pues disminiurlo no es tan trivial.
Primero, abrimos una sesión SSH hacia nuestro servidor donde estará instalado proxmox y ejecutar:
zfs list
Obtendremos los volúmenes de las máquinas virtuales y contenedores que tenemos en nuestro servidor.
En la interfaz web de nuestro servidor tenemos las máquinas y las ID, que serán importantes en este caso:
Vamos a la máquina 100 y vemos que tiene 200 gigas de disco duro:
Pongamos que queremos reducir el tamaño a 190 gigas. En la consola SSH que tenemos abierta de antes escribimos:
zfs set refquota=190G rpool/data/subvol-100-disk-0
Vemos en el nombre del disco el ID de la máquina, 100 en este caso. Ahora editaremos desde la misma consola el nuevo espacio que le hemos asignado:
vim /etc/pve/nodes/alfonsito/lxc/100.conf
Yo suelo utilizar el vim, pero queda a gusto de cada uno utilizar el editor que desee
Guardamos y salimos del archivo. Podremos comprobar en la interfaz de proxmox como el disco duro de la máquina tiene el tamaño que le hemos indicado.
Este tipo de RAID es llamado propiamente BIOS o RAID integrado en la placa base, pero es falsamente anunciado como RAID por hardware. La matriz está gestionada por controladoras pseudoRAID donde la lógica RAID se implementa en una opción de rom o en el propio firmware con un EFI SataDriver (en el caso de Unified Extensible Firmware Interface (Español)), pero no son completas controladoras de RAID por hardware con todas las funciones RAID implementadas. Por lo tanto, este tipo de RAID a veces se llama fakeRAID. dmraid disponible en los repositorios oficiales, se utilizará para suplir a estas controladoras. Algunos ejemplos de controladoras FakeRAID son: Intel Rapid Storage, JMicron JMB36x RAID ROM, AMD RAID, ASMedia 106x y NVIDIA MediaShield.
Como indica su nombre es un RAID falso, nos lo encontramos de forma frecuente en ordenadores de consumo medio que cuentan con una controladora de discos capacitada para realizar este tipo de RAIDs, y consiste básicamente en la agrupación simulada de los discos como tales para que el sistema operativo al arrancar piense que efectivamente se trata de tal agrupación de discos. La idea «imita» al funcionamiento de los RAIDs por hardware pero con unos recursos bastante más limitados y que por lógica no pueden compararse en resultados, de hecho este tipo de emparejamientos de discos suele ser el menos fiable de los diferentes métodos y si buscamos por foros veremos múltiples problemas relacionados a la pérdida del RAID montado bajo este sistema.
La ventaja es que el sistema operativo ve montado el RAID en el mismo momento que arranca, pero eso no evita que los recursos de gestión sean de la propia CPU y RAM del sistema. Además si movemos el raid a otro equipo muchas veces nos encontramos con problemas de compatibilidad entre controladoras así que es conveniente antes asegurar que no tendremos problemas entre diferentes ordenadores.
Como comentan en un post de serverfault, es preferible tener un RAID por software a un fakeRAID por tres principales razones:
Mover los discos a una nueva máquina (con un hardware diferente) funcionará sin más; no hay que buscar el mismo hardware para seguir emulando el RAID.
Se puede manipular el array con las herramientas disponibles en el sistema operativo en lugar de depender del soporte de las herramientas propietarias del fabricante, las cuales cuentan con un soporte prácticamente nulo.
En la mayoría de casos, rehacer el RAID por software es una tarea trivial; sólo habría que utilizar el mismo sistema operativo o un LiveCD.
Este router, poco conocido, es distribuido por una empresa de fibra local de mi ciudad. Pero viene batante capado.
A priori solamente podemos acceder con el usuario user y con la contraseña user (originales, ¿verdad?).
La configuración avanzada para el usuario con menos privilegio es bastante escasa.
La propia interfaz del router tiene oculto cuántos usuarios tiene este router; que son 3. En el apartado management nos vamos al subapartado de passwords. En la ventana principal (el bloque grande central) hacemos click derecho y le damos a inspeccionar elemento. Ahí veremos las tres cuentas con las que se puede acceder al router: admin, poweruser y user.
Ni que decir tiene que las combinaciones admin y admin y demás sucedáneas no funcionan.
Probamos con poweruser y poweruser como contraseña y podemos acceder sin problemas. Aquí ya hay más opciones que el usuario limitado.
Como estamos buscando acceso total, el usuario poweruser no nos vale del todo. ¿Y cómo accedemos como admin?
Primero, haciendo un escaneo de puertos, vemos que tiene abiertos tanto el 22 (SSH) como el 23 (telnet). Para acceso de administrador he usado el 22, aunque presumiblemente también se puede realizar por telnet.
Podemos acceder con PuTTY si utilizamos Windows o el comando ssh si estamos desde Linux:
ssh poweruser@192.168.1.1
En la ventana del PuTTY:
Desde Linux probablemente nos de el error:
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
Desde Windows nos saltará una advertencia como la que se puede ver en la foto de abajo:
Solamente tenemos que pulsar Sí o Yes para acceder a la pantalla de login
La pantalla donde introduciremos poweruser como usuario y como contraseña.
En el caso de Linux, podemos esquivar el error introduciendo:
Si escribimos help podemos ver una lista de comandos disponibles:
Algunos de los comandos disponibles para el usuario poweruser
Si intentamos poner comandos que no aparecen en esa lista vemos que son comandos desconocidos o no permitidos.
El comando echo si está en la lista de comandos permitidos.
Pero, usando un poco de bash scripting, podemos ejecutar comandos:
Listado de archivos
Pero no podemos ejecutar el intérprete de comandos bash, pues se queda colgado:
Pero si ejecutamos dos comandos seguidos, el segundo lo acepta sin poner pegas:
Ejecución de dos comandos en la misma línea
Pues ya tenemos acceso completo al sistema como usuario root:
Podemos ver todos los archivos.
Ahora lo que nos interesa ver es si las contraseñas se guardan en el antiguo archivo passwd o en el «nuevo» shadow, ambos situados en /etc/:
Vemos que utiliza el archivo passwd, por lo que los usuarios y contraseñas estarán ahí. Las contraseñas estarán en MD5-Crypt.
Vemos el contenido del archivo:
cat /etc/passwd
Como hacer fuerza bruta a la contraseña del admin me llevaría demasiado tiempo, he copiado la contraseña del poweruser (es una que ya conocemos) y la he machacado encima de la del admin. He utilizado el editor vi para ello, ya que suele ir en la gran mayoría de compilaciones de buso
Escribimos exit dos veces; una para salir del bash y otra para salir del router.
Ahora accedemos al router con las credenciales admin/poweruser y vamos a cambiar la contraseña del administrador. Hacemos click en los siguientes sitios siguiendo la numeración.
En el 4 ponemos:
User Name: admin
Old Password: poweruser
New Password: el que elijamos
Confirm Password: lo repetimos para comprobar que lo hemos puesto bien.
Y ya tenemos acceso completo al router con la interfaz web. También decir que en SSH no nos podemos loguear como user, pero en telnet sí, por lo que la escalada se puede realizar desde cualquiera de los dos. También se puede utilizar otro comando aparte del comando echo, como por ejemplo el comando ping.
