Zedmos

6. Casos de uso

⌘K

Ejemplos resueltos, cada uno escrito como el orden en que hay que hacer las cosas. Dan por supuesto que ha terminado la Primera configuración: un enlace de subida que funciona, una red interna y clientes que llegan a internet.

Las direcciones de los ejemplos usan los rangos de documentación. Sustitúyalas por las suyas.

Publicar un servidor

Un servidor web en 192.168.1.10 debe ser accesible desde internet en la dirección pública del equipo.

  1. Dele al servidor una dirección fija. Estática en el propio servidor, o como reserva en Services → Kea DHCP → Kea DHCPv4 para que reciba siempre la misma. Una redirección hacia una dirección que cambia es una redirección que se rompe.
  2. Cree la redirección. Firewall → NAT → Destination NAT, añada una regla: Interface*: WAN Protocol*: TCP Destination*: la dirección de la WAN, puerto 443 Redirect target*: 192.168.1.10, puerto 443 * Deje que cree la regla de cortafuegos correspondiente.
  3. Restrinja el origen si puede. Si solo lo necesitan sus sucursales, ponga sus direcciones en un alias (Firewall → Aliases) y fije como origen de la regla ese alias en lugar de any. Un servicio publicado para todo el mundo es un servicio que hay que defender de todo el mundo.
  4. Pruebe desde fuera. No desde dentro: un cliente de la LAN que llega a la dirección de la WAN sigue otro camino (y necesita reflexión). Use un móvil con datos, o Network → Diagnostics → Port Probe desde otra sede.

Cuando no funciona, en orden: ¿muestra Firewall → Log Files → Live View el paquete que llega? Si no, nunca le llegó: lo bloquea el proveedor o un equipo de arriba. Si aparece bloqueado, la regla de cortafuegos falta o está por debajo de una regla que bloquea. Si aparece como permitido y el cliente sigue sin recibir nada, el propio servidor no está escuchando o tiene su propio cortafuegos.

Segmentar con VLAN

Los invitados, las cámaras y la oficina no deberían estar en una misma red.

  1. En el conmutador, haga del puerto que va al equipo un troncal que lleve las etiquetas que va a usar. Este paso está fuera del equipo y es el que la gente olvida.
  2. Cree las interfaces. Network → Interfaces → Create new, Type: VLAN, la interfaz padre, la etiqueta y Role: LAN. Dele a cada una una dirección (192.168.20.1/24 para los invitados, por ejemplo) y su propio rango DHCP: un formulario por red.
  3. Escriba las reglas. Una interfaz nueva no permite nada hasta que usted lo diga. Para una red de invitados, la forma habitual es: Bloquear invitados → cualquier red interna* (ponga sus rangos internos en un alias y bloquee el tráfico hacia él) Permitir invitados → el DNS del equipo, si los invitados lo usan Permitir invitados → cualquier destino (internet)

En ese orden: el bloqueo tiene que ir primero, porque gana la primera coincidencia.

  1. Compruebe desde un dispositivo de invitado que llega a internet y que no puede llegar a la red de la oficina. Pruebe el «no puede» con el mismo cuidado que el «puede».

Dos enlaces de subida con conmutación por error

Una segunda línea debe tomar el relevo cuando falla la primera.

  1. Levante el segundo enlace de subida como su propia interfaz con Role: WAN (Network → Interfaces).
  2. Dele a cada pasarela una dirección de vigilancia en Network → Gateways → Configuration: algo accesible más allá del router del proveedor, como un resolutor público. Vigilar la propia pasarela solo demuestra que el router está vivo, y esa no es la pregunta.
  3. Agrúpelas. Network → Gateways → Group: la principal en el nivel 1, la secundaria en el nivel 2. Dos miembros en el mismo nivel se reparten la carga en su lugar; eso es equilibrio de carga, no conmutación por error, y rompe todo lo que exija una dirección de origen estable.
  4. Dirija el tráfico al grupo. En la regla de la LAN que permite el tráfico saliente, fije Gateway en el grupo.
  5. Pruébelo desconectando el cable. Mire cómo cambia el estado en Network → Gateways y compruebe que el tráfico sigue fluyendo. Las conexiones existentes se cortarán —se establecieron por la otra línea— y las nuevas funcionarán.

VPN entre sedes con WireGuard

Dos oficinas, 192.168.1.0/24 y 192.168.2.0/24, unidas.

En cada equipo:

  1. VPN → WireGuard → Instances, añada una instancia: un puerto de escucha (51820) y una dirección de túnel (10.10.0.1/24 en el lado A, 10.10.0.2/24 en el lado B). Anote la clave pública que genera.
  2. VPN → WireGuard → Peers, añada el otro lado: su clave pública, su dirección pública y su puerto como extremo, y unas allowed IPs que cubran la dirección de túnel y la red interna del otro lado: 10.10.0.2/32, 192.168.2.0/24 en el lado A, y el espejo en el lado B.
  3. Firewall → Rules en la WAN: permita UDP al puerto de escucha desde la dirección de la otra sede.
  4. Firewall → Rules en la interfaz del túnel: decida a qué puede llegar el otro extremo. «Todo» es una decisión, no un valor por defecto.

Compruebe VPN → WireGuard → Status: un saludo reciente en ambos lados y contadores que se mueven. Sin saludo, los dos extremos no se están hablando: revise la regla de la WAN y la dirección del extremo. Un saludo sin tráfico significa que el túnel está levantado y que el enrutado o las reglas están mal: mire primero las allowed IPs, porque son a la vez la ruta y el filtro.

Teletrabajadores

Personas que están en casa necesitan llegar a la oficina.

Con WireGuard — lo más sencillo y con el mejor rendimiento:

  1. Añada una instancia para los usuarios remotos, con una red de túnel propia (10.20.0.1/24).
  2. Para cada persona, use VPN → WireGuard → Peer generator: produce la configuración del cliente y un código QR para la aplicación del móvil. Sus allowed IPs deciden a qué pueden llegar: un /32 para su dirección de túnel y la red de la oficina que necesitan.
  3. Una regla en la WAN para el puerto de escucha; reglas en la interfaz del túnel para lo que pueden alcanzar.

Con OpenVPN — cuando los clientes tienen que atravesar redes hostiles:

  1. System → Trust: una autoridad de certificación y un certificado de servidor.
  2. VPN → OpenVPN → Instances: una instancia de servidor, TCP en el 443 si necesita sobrevivir a redes restrictivas, con la red del túnel y las rutas y el DNS que envía.
  3. Un usuario por persona (Access → Users) con un certificado de cliente.
  4. VPN → OpenVPN → Client Export le da a cada persona su perfil. Contiene su clave: envíelo por algo de confianza, no por un correo sin cifrar.

Para ambos: retire el acceso cuando alguien se vaya. En WireGuard, borre el par. En OpenVPN, revoque el certificado en System → Trust → Revocation.

Wifi de invitados con portal cautivo

Los visitantes tienen internet, en sus condiciones, sin una cuenta.

  1. Una red propia — una VLAN para los invitados (arriba), con reglas que les dejen salir y los mantengan lejos de todo lo interno.
  2. Una zona de portal — Hotspot → Administration: la interfaz de invitados, el texto de la página del portal y los límites de sesión y de ancho de banda.
  3. Cómo se autentican — un simple clic con condiciones para una cafetería, bonos para un hotel, un directorio o un servidor RADIUS donde los invitados son conocidos.
  4. Los bonos, si los usa: Hotspot → Vouchers genera un lote con un periodo de validez y los imprime. El reloj empieza con el primer uso.
  5. Véalo funcionar — Hotspot → Sessions muestra quién está conectado, y Hotspot → Log File registra cada intento.

Si la ley del lugar donde opera le exige conservar registros de quién usó la red, véase System → Compliance, y lea la advertencia que hay allí.

Detección de intrusiones y el motor de seguridad

Ver lo que hay en la red, y después actuar.

  1. Instale y configure el motor (Security and Policy → Settings): qué interfaces inspecciona y su modo de despliegue.
  2. Primero observe. Deje permisiva la política Default, active el IDS/IPS en modo detección y déjelo funcionar un día.
  3. Lea lo que encontró — Security and Policy → Reports y las tarjetas del panel del motor. Cuente con falsos positivos; son la razón del paso 2.
  4. Después deje que bloquee. Active la prevención para las categorías de reglas que haya confirmado, no para todas a la vez.
  5. Prepárese una lista de exclusiones antes de necesitarla: el terminal de pago, el equipo de copias de seguridad, la máquina que habla con el proveedor de contabilidad: Exclusions en la política.

Inspección TLS

Inspeccionar el tráfico cifrado: lo que cuesta y cómo hacerlo bien.

La mayor parte del tráfico va cifrada, así que un analizador que no puede ver dentro ve poco. La inspección funciona terminando el TLS en el equipo y volviendo a emitir el certificado desde una autoridad propia, lo que significa que cada cliente debe confiar en esa autoridad, y que cada cliente que lo hace confía su tráfico al equipo.

  1. Cree la autoridad — System → Trust → Authorities. Una CA de larga duración cuyo nombre diga lo que es.
  2. Distribúyala a los clientes — por directiva de grupo, por MDM o a mano. Un cliente que no confía en ella ve errores de certificado en todos los sitios, lo cual parece exactamente un ataque, porque técnicamente lo es.
  3. Active el proxy TLS — Security and Policy → Settings → TLS Proxy, con esa CA.
  4. Active la inspección en una política — TLS & Transport en la política que cubre los dispositivos afectados.
  5. Excluya lo que no debe inspeccionarse — banca, salud, sitios de la administración pública y todo lo que use fijación de certificados (que fallará de todos modos).

La inspección es una decisión con peso legal y ético. En muchas jurisdicciones hay que informar a los empleados, y ciertas categorías de tráfico no deben interceptarse nunca. Decida la política con su organización antes de activar la función, no después.

Una pareja de alta disponibilidad

Dos equipos, para que una avería sea invisible.

  1. Constrúyalos igual: la misma versión, las mismas interfaces, el mismo cableado.
  2. Un enlace dedicado entre ellos para la sincronización.
  3. Direcciones CARP — Network → Virtual IPs en cada interfaz que usen los clientes. Los clientes apuntan a la dirección CARP, nunca a la propia de un nodo.
  4. Sincronización del estado por el enlace dedicado, para que las conexiones sobrevivan a una conmutación.
  5. Sincronización de la configuración — High Availability → Settings, solo en el maestro, apuntando a la reserva.
  6. Pruebe la conmutación: reinicie el maestro y mire High Availability → Status en la reserva. Después, vuelva atrás.

Una pareja a la que nunca se ha hecho conmutar a propósito no está probada.

Listas de bloqueo DNS

Bloquear la publicidad, el rastreo y los dominios maliciosos conocidos, en toda la red.

Services → Unbound DNS → Blocklists: suscríbase a las listas que quiera, añada sus propias entradas y guarde. Los clientes que usan el equipo como resolutor quedan cubiertos sin instalar nada.

Dos advertencias que conviene conocer: un cliente que usa su propio resolutor DNS-over-HTTPS se salta todo esto por completo (bloquee o redirija el DNS saliente si eso importa), y una lista de bloqueo acabará rompiendo algún sitio que alguien necesita: mantenga una lista de permitidos y diga a la gente cómo pedir que se añada algo.

Anterior5.12 EnergíaSiguiente7. Mantenimiento