De un VPS comercial al salón de casa. Parte 5 – Conclusiones después de un año

A lo largo de un año he sufrido unas cuantas penurias, desde fallos tontos de configuración hasta un corte de línea de 24 horas. Aun así, me siento orgulloso de transmitiros que es posible sobrevivir a la parte de administración y que el aprendizaje es arduo y continuo. La evolución ha sido progresiva y, en algunos casos, obligada, siendo más relevante la parte del hardware que la del software. Son pocas cosas, pero las voy a separar en puntos independientes para que quede más claro.

Tomar el control de tu red

El primer problema que me encontré estuvo relacionado con el router de mi proveedor y con bloqueos del servicio aproximadamente una vez por semana. Esto me trajo por la calle de la amargura durante un par de meses, ya que estuve revisando y cambiando configuraciones intentando resolver el problema hasta que llegué a la conclusión de que no estaba en mi red, sino en el propio router del proveedor, ya que todo se solucionaba tras reiniciarlo. Cuando pasó esto, el router del proveedor estaba funcionando como gateway de mi red, pero aun así se saturaba.

Investigando un poco vi que la solución pasaba por sustituir el router del proveedor por una ONT y utilizar mi propio router. Una ONT, explicado de forma sencilla, no es más que el dispositivo que convierte la conexión de fibra óptica en una conexión Ethernet que después puedes conectar a tu router.

Yo lo hice a través de mi proveedor, que no me puso ninguna pega. Lo solicité mediante atención al cliente y me lo mandaron de forma gratuita, aunque no todos los proveedores funcionan igual. Otra opción es comprar tu propia ONT, aunque esto requiere saber qué tipo necesitas, conocer los parámetros necesarios para conectarte a la red del operador y asumir que no siempre va a funcionar.

Aproveché la instalación de la ONT para modernizar mi red local y poder sacar provecho a los 2,5 GbE de su salida Ethernet. El router que he instalado es un MikroTik RB5009, que tiene potencia suficiente para mi montaje, un puerto de 2,5 GbE, siete puertos Gigabit Ethernet y un puerto SFP+ de 10 GbE que me permite ampliar la red con otros dispositivos (esto es irrelevante para el servidor, pero os lo cuento para chulear ;-)).

La elección del router es muy personal e incluso puede que os parezca una exageración gastarse 200 € en uno, pero tened en cuenta que este tipo de equipos te dan la flexibilidad suficiente para todo tipo de configuraciones y futuras necesidades.

La MicroSD no es suficiente

Después de algún reinicio de la Raspberry Pi me pareció que tardaba más de la cuenta en arrancar. De nuevo tardé en darme cuenta de que el problema no era de configuración, sino de hardware, más concretamente de la tarjeta MicroSD.

Antes de que la MicroSD se dañase más de la cuenta hice una imagen de ella y la grabé en un disco M.2 NVMe. Era el momento ideal para aprovechar y mejorar también la fiabilidad del almacenamiento, por lo que compré un segundo disco M.2 NVMe junto a una placa dual conectada a la Raspberry Pi mediante PCIe.

Esta placa y los dos discos me han permitido montar un RAID1 y ganar bastante tranquilidad ante el fallo de uno de los discos. Por supuesto, un RAID1 no sustituye a una copia de seguridad, pero evita que la caída de una única unidad deje el servidor fuera de servicio.

La creación del RAID1 tiene su miga y requiere de unos cuantos comandos que no voy a colgar aquí para no enmarañar la entrada.

Problemas con Duck DNS

No puedo daros una respuesta técnica sobre los problemas que sufrí con Duck DNS, pero el caso es que tuve varios episodios de fallo de comunicación, con el correspondiente lío de IPs, y al final decidí prescindir del servicio.

Como ya gestiono mis dominios con Dynadot, terminé creando un pequeño script que utiliza su API para actualizar automáticamente la IP pública asociada al dominio. En la práctica hace la misma función que necesitaba de Duck DNS, pero utilizando directamente mi propio dominio y sin depender de un segundo servicio.

#!/usr/bin/env bash
set -euo pipefail

DYNADOT_API_KEY="tu_API_key"

DOMINIOS=(
  "dominio_uno.info"
  "dominio_dos.info"
  "dominio_tres.info"
  "dominio_cuatro.net"
)

IP_ACTUAL="$(curl -4 -fsS https://api.ipify.org)"

if [[ ! "$IP_ACTUAL" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}$ ]]; then
  echo "ERROR: No se pudo obtener la IP pblica. IP_ACTUAL='$IP_ACTUAL'"
  exit 1
fi

for DOMINIO in "${DOMINIOS[@]}"; do
  echo "Actualizando $DOMINIO -> $IP_ACTUAL"

  # OJO: set_dns2 SOBRESCRIBE la zona DNS por defecto.
  # Por eso aqu fijamos explcitamente: raz (A) y www (A).
  RESP="$(
    curl -fsS -G "https://api.dynadot.com/api3.json" \
      --data-urlencode "key=$DYNADOT_API_KEY" \
      --data-urlencode "command=set_dns2" \
      --data-urlencode "domain=$DOMINIO" \
      --data-urlencode "main_record_type0=a" \
      --data-urlencode "main_record0=$IP_ACTUAL" \
      --data-urlencode "subdomain0=www" \
      --data-urlencode "sub_record_type0=a" \
      --data-urlencode "sub_record0=$IP_ACTUAL" \
      --data-urlencode "ttl=300"
  )"

  echo "$RESP"
done

echo "Actualizacion completada."

Dale a la seguridad la importancia que se merece

Cuando tienes un servidor encendido las 24 horas y accesible desde Internet, la seguridad deja de ser algo opcional. Antes o después vas a ver intentos de acceso, robots buscando vulnerabilidades, peticiones contra servicios que ni siquiera tienes instalados y todo tipo de tráfico que probablemente nunca verías utilizando una conexión doméstica de forma convencional.

Aquí es donde disponer de un router sobre el que tengas control real empieza a tener bastante sentido. Puedes definir exactamente qué tráfico entra y sale de tu red, crear reglas de firewall específicas, separar dispositivos mediante VLAN, limitar el acceso entre diferentes partes de la red o evitar directamente publicar determinados servicios en Internet.

Una de las cosas que he ido cambiando durante este año ha sido precisamente mi filosofía respecto a la apertura de puertos. Al principio es muy tentador pensar que, si necesitas acceder a un servicio desde fuera de casa, basta con abrir su puerto correspondiente en el router. Funciona, pero cada puerto que publicas es también una nueva puerta que tienes que vigilar y mantener actualizada.

Siempre que puedo prefiero utilizar una VPN y acceder a mi red doméstica como si estuviera físicamente conectado a ella. De esta forma puedo administrar el servidor, entrar en servicios internos o acceder a diferentes equipos sin necesidad de exponerlos individualmente a Internet. Evidentemente sigo teniendo servicios que necesariamente deben ser públicos, como el servidor web, pero intento que sean los mínimos posibles.

Esto tampoco significa que por instalar un buen router tu red pase mágicamente a ser segura. El router es únicamente una de las capas. Hay que mantener actualizado el sistema operativo, los servicios que publicas, WordPress y sus plugins si tienes una web como la mía, utilizar contraseñas seguras, revisar periódicamente los registros y tener copias de seguridad que realmente puedas recuperar.

De hecho, durante este año he tenido algún recordatorio bastante poco sutil de que estas cosas conviene tomárselas en serio. Tener tu propio servidor es muy entretenido cuando todo funciona, pero también significa convertirte, quieras o no, en su administrador de sistemas. Y esa parte del aprendizaje probablemente sea tan importante como montar el propio servidor.