Múltiples máquinas, un solo túnel VPN

Una confusión frecuente: los clientes creen que cada máquina necesita su propio túnel VPN. Falso. Un túnel VPN es un sitio físico — no una máquina. Dentro de ese sitio pueden colgar cuantos equipos quieras, de protocolos distintos, sin tocar el router VPN.

¿Para qué sirve este caso?

Para entender el modelo mental correcto antes de escalar una panadería, fábrica u oficina de 1 a N máquinas conectadas. La gente que viene del mundo "una VPN por proveedor" espera configurar un túnel por equipo — nosotros trabajamos al revés: un túnel por sitio, N sources por túnel.

¿Cómo funciona?

El túnel WireGuard transporta paquetes IP arbitrarios. Cuando nuestro worker manda Modbus a 192.168.1.51:502, tu router Mikrotik:

1. Recibe el paquete por la interfaz rela-vpn.
2. Mira su tabla de rutas: 192.168.1.0/24 vive en ether1 (tu LAN).
3. Forwardea al switch, que lo entrega al PLC correcto.

Al PLC le llega una conexión TCP normal desde 10.200.7.2 (la IP VPN asignada a tu sitio). No le importa ni sabe que hay un túnel entremedio.

Si querés leer 15 PLCs en paralelo, el worker abre 15 conexiones TCP diferentes — todas atravesando el mismo túnel. El ancho de banda agregado suele estar por debajo de 1 Mbps: Modbus y OPC UA son tráfico chico.

                        ┌─────────────────────────┐
 [Rela AI Worker] ─────▶│ Túnel WireGuard (UDP)   │
                        └──────────┬──────────────┘
                                   │
                         ┌─────────▼──────────┐
                         │   Mikrotik hAP ac3 │
                         │   (tu planta)      │
                         └─────────┬──────────┘
                                   │  LAN 192.168.1.0/24
          ┌────────────┬───────────┼───────────┬────────────┐
          ▼            ▼           ▼           ▼            ▼
     Cámara       Horno       Amasadora   Compresor    Sensor temp
   Modbus TCP   Modbus TCP     S7comm     EtherNet/IP    OPC UA
     .50          .51           .52          .53          .60

Beneficios

Cuándo UN túnel es suficiente

Cuándo necesitás MÚLTIPLES túneles

La regla: un túnel = un sitio físico con red LAN común. Si las redes no se tocan físicamente, necesitás un túnel por cada una.

Paso a paso — Agregar una máquina al túnel existente

Asumamos que ya tenés la cámara de fermentación andando por VPN. Ahora querés monitorear también el horno rotativo.

1. Asignale IP fija al horno (10 min)

Desde el panel del horno (o el software del fabricante), asignale IP estática en la misma subnet que la cámara:

• IP: 192.168.1.51
• Máscara: 255.255.255.0
• Gateway: IP del router ISP (el mismo que para la cámara)

2. Verificá alcance desde el Mikrotik

Desde la consola del Mikrotik:

/tool ping count=4 address=192.168.1.51

Deben responder los 4 pings. Si no:

• El horno no tiene el servicio Modbus/OPC UA activo — revisá config del equipo.
• Hay un firewall interno de la planta separando switches — consultá con IT.

3. Identificá protocolo del horno

Los hornos industriales suelen hablar:

• Modbus TCP (90% de casos post-2015).
• OPC UA (equipos premium, p.ej. hornos modulares de Miwe o Revent con panel smart).
• S7comm (Siemens específicamente).

Revisá el manual o la etiqueta del PLC. Si no sabés, intentá Modbus TCP primero — falla rápido.

4. Dashboard → Nueva fuente

No cambies nada en el Mikrotik. El mismo túnel ya cubre 192.168.1.0/24, así que la nueva IP entra por el mismo camino.

5. Register map

Si el horno expone temperatura de cámara y estado de resistencias:

6. Crear agente diferenciado

Crea un agente separado para el horno:

• Nombre: Agente Hornos
• Severidad mínima: warning
• Reglas específicas:
  • horno.temperatura_camara > 280 during 2min → high (sobre-temperatura peligrosa).
  • horno.temperatura_camara < 150 AND horno.resistencias_activas == true during 10min → warning (problema de potencia).
  • horno.ventilador_activo == false AND horno.temperatura_camara > 200 → critical (ventilador muerto con carga).

7. Validar

Encender el horno. A los 30 segundos deberías ver eventos horno.temperatura_camara en el inbox con valores crecientes. Si los ves, terminaste.

Plan limits y peers

Una panadería con 1 local + 50 máquinas está en plan Essential. Una cadena de 5 panaderías con 10 máquinas cada una, en Enterprise. Una cadena de 20 panaderías, presupuesto custom.

Troubleshooting específico de multi-máquina

Agregué una fuente nueva pero el test falla

Probá desde el Mikrotik:

/tool ping count=4 address=<IP-nueva-máquina>

Si el ping falla, el problema está en tu LAN (VLAN segregada, firewall de planta, IP mal asignada). Si el ping funciona pero el test Modbus falla, chequeá el register map y el unit_id.

Todas las fuentes muestran connected pero una no llega al inbox

La fuente específica tiene un problema propio. Las causas más frecuentes:

• Emit policy threshold_crossed y el valor nunca cruza el umbral.
• Agente asignado tiene min_severity=critical y los eventos son info.
• Poll interval muy largo (ej. 60s) — no hay eventos suficientes todavía.

Latencia aumenta conforme agrego máquinas

El polling de cada fuente es independiente y asíncrono. Agregar 10 máquinas a una VPN no añade latencia significativa a cada una — salvo que saturen el ancho de banda del túnel (>10 Mbps sostenidos).

Si ves latencias subiendo, el cuello suele ser el PLC lento, no la VPN. Revisá con los timings de Prometheus modbus_poll_latency_seconds{source_id="<id>"}.

Limitaciones

• Subnet de la VPN fija: tu sitio tiene 10.200.X.0/24 asignado permanentemente. No podemos cambiarla sin eliminar y recrear el peer.
• Routing desde el Mikrotik a todas las LANs OT: si tu planta tiene múltiples subnets OT (192.168.1.0/24, 192.168.2.0/24, 10.10.0.0/24), el Mikrotik tiene que tener rutas a todas.
• Multicast NO va: WireGuard sólo transporta unicast. Protocolos basados en multicast (BACnet broadcast, EtherNet/IP discovery) no atraviesan el túnel — cada dispositivo debe tener IP directamente alcanzable.

Ver también: Conectividad VPN — guía técnica, Conectar una panadería desde cero, Conexión Modbus TCP.