Construyamos una fortaleza: Homelab v1.0
Durante mucho tiempo, he soportado enrutadores alquilados por ISP al azar en mi red doméstica o enrutadores que venían con los apartamentos donde me hospedaba. Estos dispositivos suelen ser de código cerrado, inflados, carentes de actualizaciones de seguridad adecuadas, de configurabilidad limitada y la lista continúa. Estas características reducen en gran medida la seguridad de nuestra red y nuestro control sobre el tráfico de red entre dispositivos de la red interna y entre el enrutador y el Internet. Esto estaría bien si solo me importara la seguridad y el control de una sola computadora, pero ahora también tengo un servidor raspberry pi 5, otra persona importante que quiero proteger con una VPN y otros mecanismos, así como más servidores que probablemente vendrán, como por ejemplo:
- Una caja de IA local cuyo tráfico de red está estrictamente controlado porque todos sabemos que las IAs locales son como entidades desconocidas convocadas desde otra dimensión donde necesitamos configurar muchas barreras mágicas para asegurarnos de que cumpla nuestras órdenes y no al revés.
- Servidores para ejecutar o mostrar soluciones para clientes que aprecian la seguridad y la privacidad y no tener que confiar también en algún proveedor aleatorio de nube o VPN además de mí.
- Autohospedaje de muchas cosas, para mí y mi pareja, por ejemplo un NAS y un Chat local.
- Servidores públicos en una DMZ.
Esta configuración de red es esencialmente el comienzo de lo que podemos llamar un laboratorio doméstico. Esta primera versión del laboratorio que describo en este artículo es mínima y simple, como se muestra en la imagen a continuación, pero está diseñada para ser ampliable con un conmutador de red administrado de capa 2, lo cual haré más adelante:
En las siguientes secciones hablaré sobre cada componente notable de la configuración de la red. Cambié y omití algunas partes no esenciales de mi configuración, pero esto debería dar una idea general. Para ser breve, me salto todos los comandos que realmente pueden activar las configuraciones que comparto. Asumo que el lector consulte la documentación de OpenBSD y OpenWRT para obtener detalles adicionales. Con todas las configuraciones implementadas, debería ser suficiente reiniciar los dispositivos configurados para que todos se activan a la vez. Siempre me ha ayudado revisar configuraciones de ejemplo junto con mi aprendizaje, así que espero que esto pueda ser útil para alguien.
Enrutador
Los requisitos que tenía para el enrutador fueron los siguientes:
- Ejecuta OpenBSD
- Lo suficientemente potente como para no ser demasiado limitante para el uso creativo de PF (el cortafuegos de OpenBSD y más) en el futuro
- Ejecuta tanto software libre como sea posible en el firmware, como con Coreboot
- Tiene Motor de Gestión Intel (IME) deshabilitado si la arquitectura es x86
- Está completamente cableado, sin hardware inalámbrico
- Tiene 4+ puertos de red
La elección obvia después de algunas búsquedas en Internet fue uno de esos enrutadores Vault Pro de Protectli y elegí el VP2440 sin chips inalámbricos y con Dasharo Coreboot que desactiva IME. De hecho, estaba bastante interesado en una de esas APUs de PC Engines, pero PC Engines ya no está activo desde hace algún tiempo. Son más baratos, tienen menos hardware redundante que realmente no necesito y no tienen IME. Tienen algo similar al IME llamado Procesador de Seguridad de Plataforma (PSP), pero es algo menos severo, pero sigue siendo malo. Oye, desearía que los fabricantes de hardware detuvieran estas travesuras de puertas traseras, pero todo lo que puedo hacer es al menos desactivar lo que pueda. Algo más que tiene el VP2440 sobre una APU son dos puertos SFP+ que permiten una conectividad de 10Gb. Si bien por ahora solo necesito una conexión de 1 Gb, pensé que sería bueno tener esa posibilidad para estar más preparado para el futuro.
Configuré OpenBSD sin ningún conjunto de archivos X, pero mantuve el archivo de compilación configurado en caso de que pudiera necesitarlo mientras todavía me estoy acostumbrando a OpenBSD. Una vez que tenga más experiencia, posiblemente también pueda eliminar ese conjunto de archivos para mayor seguridad. Elegí el nombre de host “steelix”. Sí, elegí un tema de pokémon para mis nombres de host para algo de diversión y nostalgia. Una vez tuve un Steelix que se volvió prácticamente indestructible al aumentar sus defensas con hierro y aumentos de HP cada vez que podía. Creo que esa descripción encaja muy bien con mi intención para este enrutador.
ISP y puerto WAN
Al tener un enrutador con un puerto SFP+, pude conectar el cable de fibra óptica de un ISP directamente al enrutador a través de una ONT SFP de 1 Gb y aumentarlo a una ONT SFP de 10 Gb en el futuro si fuera necesario. Esto elimina la necesidad de tener la caja ONT habitual y permite que mi enrutador obtenga una dirección IP WAN directamente del ISP, lo que simplifica en general la configuración. Aquí en Islandia, solo conocí un proveedor mayorista de fibra óptica que admitía la conexión a través de SFP ONT, y ese es el más grande Míla. También necesitaba encontrar un ISP que proporciona direcciones IP estáticas mientras me conectaba a través de Míla, y uno que encontré fue Hringiðan. La IP está ligada a las credenciales PPPoE que te dan. Luego, para conectarme al Internet en el enrutador, puse lo siguiente en /etc/hostname.pppoe0, reemplazando authname y authkey con mis credenciales:
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev ixl0 authproto chap \
authname 'authname' authkey 'authkey' up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
También puse un simple up en /etc/hostname.ixl0, para activar la interfaz física a la que está conectado el cable de fibra óptica y SFP ONT.
Punto de acceso inalámbrico
No tener conectividad inalámbrica en el enrutador fue deliberado y para mayor seguridad de este corazón de la red. La conectividad inalámbrica añade complejidad y cualquiera que esté lo suficientemente cerca puede intentar conectarse, lo que significa más vectores de ataque potenciales. Por ahora todavía queremos conectividad inalámbrica en nuestro hogar, por lo que la idea es tener un punto de acceso inalámbrico (WAP) separado que sea fácil de contener. Lo que he aprendido de OpenBSD es que la conectividad inalámbrica a menudo tiende a no ser tan compatible, lo cual es comprensible ya que es un dominio complejo que a menudo requiere más mano de obra que hay disponible para un sistema operativo como este, y tal vez tampoco sea la máxima prioridad debido a su enfoque en la seguridad. Así que limité mi búsqueda a enrutadores que ejecutan OpenWRT, ya que OpenWRT y Linux en general tienen más soporte inalámbrico. OpenWRT es una distribución de Linux bastante simplificada sin systemd y tanta complejidad, así que lo veo como una ventaja para la seguridad.
Primero tuve mis ojos en el enrutador start9, principalmente porque se ejecuta en una arquitectura de computadora RISC-V que libera a los fabricantes de hardware de tener que pagar tarifas por usarlo, como es la norma en otros casos. De hecho, el uso de RISC-V descentraliza más la fabricación, brinda soporte a los fabricantes más pequeños y nos brinda más opciones para nuestra cadena de suministro de hardware, algunas de las cuales, con suerte, resultarán más confiables y sin puerta trasera. Sin embargo, realmente necesitaba pronto un WAP utilizable, así que decidí esperar con eso. Al final decidí optar por el enrutador OpenWRT One para que sirviera como un WAP tonto. Cuándo hablo de un enrutador en adelante, estoy hablando de VP2440.
Una cosa interesante que puedes hacer con OpenWRT es tener múltiples redes inalámbricas a las que puedas conectarte en un WAP, y puedes tener cada red en una VLAN separada, que es lo que hice. Esos VLANs pueden tener niveles de privilegio separados establecidos en las tablas de enrutamiento y el cortafuegos del enrutador, como niveles diferentes para invitados, la familia, etc. También podría intentar instalar un paquete Tollgate en el WAP en una VLAN separada en algún momento, porque sería genial saber que podría cobrar a extraños al azar por conectarse si quisiera.
Mi configuración de OpenWRT en el WAP es similar a la siguiente, comenzando con /etc/config/network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdab:853:1fb8::/48'
config interface 'privileged'
option type 'bridge'
option stp '1'
option ifname 'eth0.3'
option proto 'none'
option auto '1'
option delegate '0'
config interface 'family'
option type 'bridge'
option stp '1'
option ifname 'eth0.4'
option proto 'none'
option auto '1'
option delegate '0'
config interface 'br-lan'
option type 'bridge'
option stp '1'
list ifname 'eth0.5'
list ifname 'eth1'
option proto 'none'
option auto '1'
option delegate '0'
config interface 'guest'
option type 'bridge'
option stp '1'
option ifname 'eth0.6'
option proto 'none'
option auto '1'
option delegate '0'
Todas, excepto las cuatro últimas definiciones de interfaz, estaban en la configuración de forma predeterminada. Cada una de esas cuatro interfaces tiene una list ifname 'eth0.N', lo que significa que conecta el puerto ethernet eth0 (que se conecta al enrutador) con el tráfico etiquetado como VLAN N. La interfaz br-lan une el segundo puerto ethernet y las otras tres interfaces se utilizan para sus respectivas redes inalámbricas en /etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/18000000.wifi'
option band '2g'
option channel '1'
option htmode 'HE20'
option num_global_macaddr '7'
option disabled '0'
option country 'IS'
config wifi-iface 'privileged_radio0'
option device 'radio0'
option network 'privileged'
option mode 'ap'
option ssid 'Eagle'
option encryption 'psk2'
option key 'some-password'
config wifi-iface 'family_radio0'
option device 'radio0'
option network 'family'
option mode 'ap'
option ssid 'Shrimp'
option encryption 'psk2'
option key 'some-password'
config wifi-iface 'guest_radio0'
option device 'radio0'
option network 'guest'
option mode 'ap'
option ssid 'Magpie'
option encryption 'psk2'
option key 'some-password'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option band '5g'
option channel '36'
option htmode 'HE80'
option num_global_macaddr '7'
option disabled '0'
option country 'IS'
config wifi-iface 'privileged_radio1'
option device 'radio1'
option network 'privileged'
option mode 'ap'
option ssid 'Eagle'
option encryption 'psk2'
option key 'some-password'
config wifi-iface 'family_radio1'
option device 'radio1'
option network 'family'
option mode 'ap'
option ssid 'Shrimp'
option encryption 'psk2'
option key 'some-password'
config wifi-iface 'guest_radio1'
option device 'radio1'
option network 'guest'
option mode 'ap'
option ssid 'Magpie'
option encryption 'psk2'
option key 'some-password'
Cada interfaz inalámbrica se define una vez para cada banda de frecuencia que se puede utilizar. Eso es todo lo que se necesita para que un WAP funcione.
VPN con Wireguard y Rdomains
Quería que algunos de mis dispositivos conectados usaran una VPN y otros no, así que en lugar de pasar por el obstáculo de configurar la VPN en cada dispositivo, simplemente agregué un nuevo rdomain en el enrutador, una red separada que enruta el tráfico no interno a través de una interfaz Wireguard. De esta manera, tampoco necesito lidiar con las complicaciones de lograr que mis dispositivos se comuniquen entre sí a través de la LAN si algunos de ellos están conectados a una VPN. Para configurar esto, creé /etc/hostname.wg0:
rdomain 1
wgkey <private-key>
wgpeer <public-key> wgendpoint <ip-address-1> <port> wgaip 0.0.0.0/0
inet <ip-address-2> 255.255.255.255
!route -T1 add default -net <ip-address-2>
Luego completé los detalles entre corchetes según mi proveedor de VPN.
puertos LAN
Conecté un adaptador SFP-Ethernet al puerto SFP+ restante, y con eso tenía 3 puertos Ethernet para la LAN. Quería que uno de ellos estuviera en la VPN y el otro donde se conecta el WAP. La red inalámbrica “Eagle” debía también estar en la VPN, así que tuve que asegurarme de que VLAN 3 estuviera configurada así. Para configurar esto, puse el puerto LAN en la VPN en /etc/hostname.ixl1:
rdomain 1
inet 192.168.10.1 255.255.255.0 192.168.10.255
Puse el puerto LAN normal en /etc/hostname.igc0:
inet 192.168.20.1 255.255.255.0 192.168.20.255
Para el puerto WAP LAN, simplemente escribí up en /etc/hostname.igc1 e hice las VLANs también, comenzando con la VLAN en la VPN en /etc/hostname.vlan0:
create
parent igc1 vnetid 3
rdomain 1
inet 192.168.3.1 255.255.255.0 192.168.3.255 description "AP Privileged"
Luego el resto de las VLANs, comenzando con /etc/hostname.vlan1:
create
parent igc1 vnetid 4
inet 192.168.4.1 255.255.255.0 192.168.4.255 description "AP Family"
Luego /etc/hostname.vlan2:
create
parent igc1 vnetid 5
inet 192.168.5.1 255.255.255.0 192.168.5.255 description "AP LAN port"
Y finalmente etc/hostname.vlan3:
create
parent igc1 vnetid 6
inet 192.168.6.1 255.255.255.0 192.168.6.255 description "AP Guest"
DHCP y DNS
En el enrutador utilizo dhcpd para distribuir IP, rutas por defecto y servidores DNS a todos los dispositivos y unbound como servidor DNS. Puse esto en /etc/dhcpd.conf:
subnet 192.168.20.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.20.1;
option routers 192.168.20.1;
range 192.168.20.2 192.168.20.254;
}
# Family
subnet 192.168.4.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.4.1;
option routers 192.168.4.1;
range 192.168.4.2 192.168.4.254;
}
# AP LAN
subnet 192.168.5.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.5.1;
option routers 192.168.5.1;
range 192.168.5.2 192.168.5.254;
}
# Guest
subnet 192.168.6.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.6.1;
option routers 192.168.6.1;
range 192.168.6.2 192.168.6.254;
}
y en la sección del servidor de /var/unbound/etc/unbound.conf:
server:
interface: 192.168.20.1
interface: 192.168.4.1
interface: 192.168.5.1
interface: 192.168.6.1
interface: 127.0.0.1
#interface: 127.0.0.1@5353 # listen on alternative port
interface: ::1
#do-ip6: no
# override the default "any" address to send queries; if multiple
# addresses are available, they are used randomly to counter spoofing
#outgoing-interface: 192.0.2.1
#outgoing-interface: 2001:db8::53
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: 192.168.20.0/24 allow
access-control: 192.168.4.0/24 allow
access-control: 192.168.5.0/24 allow
access-control: 192.168.6.0/24 allow
...
Me aseguré de habilitarlos:
rcctl enable dhcpd unbound
Sin embargo, las configuraciones anteriores solo funcionan para rdomain 0, ya que dhcpd y unbound usan solo la pila de red asociada con un rdomain a la vez. Por lo tanto, necesitaba crear una segunda configuración de dhcpd /etc/dhcpd1.conf:
subnet 192.168.10.0 netmask 255.255.255.0 {
option domain-name-servers <ip-address>;
option routers 192.168.10.1;
range 192.168.10.2 192.168.10.254;
}
# Privileged
subnet 192.168.3.0 netmask 255.255.255.0 {
option domain-name-servers <ip-address>;
option routers 192.168.3.1;
range 192.168.3.2 192.168.3.254;
}
Elegí que la dirección IP de domain-name-servers fuera la proporcionada por el proveedor de VPN. Luego todo lo que quedaba era crear una segunda instancia de dhcpd que use esa configuración y rdomain 1:
ln -s /etc/rc.d/dhcpd /etc/rc.d/dhcpd1
rcctl set dhcpd1 flags -c /etc/dhcpd1.conf -l /var/db/dhcpd1.leases
rcctl set dhcpd1 rdomain 1
rcctl enable dhcpd1
Cortafuegos y NAT
Para mantener un control estricto sobre el tráfico de la red, configuré PF de OpenBSD en el enrutador. Me basé en algunas configuraciones de ejemplo e hice algunos experimentos hasta que me decidí por la siguiente configuración en /etc/pf.conf:
int_if_1 = "ixl1"
int_if_2 = "igc0"
wap = "igc1"
int_ifs = "{" $int_if_1 $int_if_2 vlan "}"
table <int_networks> const { $int_if_1:network $int_if_2:network vlan:network }
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
203.0.113.0/24 }
set skip on lo
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from ! (egress:network) to ! <int_networks> nat-to (egress:0)
match out on wg0 inet from ! (wg0:network) to ! <int_networks> nat-to (wg0:0)
antispoof quick for { egress $int_if_1 $int_if_2 vlan }
block in quick on egress from <martians> to any
#block return out quick on egress from any to <martians>
block all
pass out on { egress wg0 } inet
pass out on $int_if_1 proto tcp from $int_if_2:network to port { ssh }
pass out on vlan0 proto tcp from $int_if_2:network to vlan0:network port http
pass in on $int_ifs inet
pass in on $int_if_2 proto tcp to $int_if_1:network port { ssh } rtable 1
pass in on $int_if_2 proto tcp to vlan0:network port http rtable 1
En resumen, todo el tráfico que se origina desde el Internet hacia el enrutador está bloqueado, pero todo el tráfico que se origina desde la LAN está permitido hacia el Internet. Los dispositivos en la LAN no pueden comunicarse entre sí, excepto que puedo entrar por ssh desde mi computadora portátil a mi raspberry pi raichu y acceder a algunas interfaces a través de http en la red inalámbrica Eagle/VLAN 3. También pongo todo el tráfico por NAT antes de salir al Internet.
Con todas estas configuraciones implementadas y el enrutador y WAP reiniciados y conectados como se muestra en la imagen al comienzo del artículo, ¡homelab v1.0 está listo!
Conclusión
Esta configuración básica ha resultado bastante útil para mí y para mi pareja, y la ampliaré y modificaré gradualmente a medida que pase el tiempo. Pasar por esto me ha enseñado mucho y me ha dado una mayor apreciación de lo que OpenBSD y OpenWRT pueden ofrecer a la causa de reclamar un control real sobre una red. Un efecto de tener tanto control sobre la red con un sistema operativo centrado en la seguridad como OpenBSD es que soy mucho menos reacio a ejecutar cualquier tipo de sistema operativo inflado, de caja negra, de pesadilla de seguridad y sus aplicaciones en una caja, diablos, ni siquiera las cajas de Windows me afectarán ahora. Mientras que las facultades de red de la caja estén bajo mi control, puedo manejarlo con seguridad.
Espero que este artículo haya sido útil o al menos inspirador y agradezco cualquier comentario o idea. ¡Hasta la próxima!
Comentarios
Accede a la sección de comentarios del post en Nostr con su app por defecto o app de web.