Cómo probar que la VPN funciona

Esta guía está escrita para el técnico de IT del cliente — alguien que acaba de pegar la configuración WireGuard en su router y quiere confirmar que todo está operativo antes de pasarle el testigo al equipo de planta. Cada paso incluye el comando exacto y el resultado esperado.

¿Para qué sirve esta guía?

Para que un pegar-y-olvidar no se convierta en "a las 2 AM del lunes nadie llega al PLC". Vas a verificar 6 capas en orden: handshake → routing → conectividad IP → puerto TCP → Modbus request → dashboard. Si alguna falla, el mensaje de error apunta exactamente a la capa culpable.

¿Cómo funciona el diagnóstico por capas?

Cuando una conexión WireGuard no anda, el error casi siempre está en UNA capa específica — y cada capa tiene su propia herramienta de diagnóstico. Ir de abajo hacia arriba (handshake primero, Modbus al final) te ahorra horas de "revisé todo y no funciona".

Beneficios

Pre-requisitos

Antes de empezar:

• Configuración WireGuard aplicada en tu router/firewall (ver Alta y Configuración).
• Acceso terminal (SSH / consola web) al router o al equipo que está corriendo WireGuard.
• IP privada del PLC conocida (dentro de tu red local).
• Subnet asignada por Rela AI (se ve en el dashboard al crear el peer — formato 10.200.X.0/24).

Capa 1 — Handshake WireGuard

Verificamos que tu router y el concentrador de Rela AI se saludaron.

pfSense / OPNsense

Menú: Status → WireGuard. Deberías ver:

• Interfaz rela_vpn en verde.
• En el peer, Latest Handshake con valor menor a 2 minutos.
• Transfer con bytes crecientes (rx y tx).

Mikrotik RouterOS

/interface wireguard peers print

Resultado esperado:

 # INTERFACE=rela-vpn  PUBLIC-KEY=clrU9+Aj...  LAST-HANDSHAKE=15s  RX=2.8KiB  TX=3.1KiB

Si LAST-HANDSHAKE dice never o un número muy grande (>1 hora), el handshake nunca ocurrió. Salta a troubleshooting: Capa 1.

Ubiquiti EdgeOS

show interfaces wireguard wg0

Busca peer: <pubkey> seguido de latest handshake: X seconds ago.

Linux (wg-quick)

sudo wg show wg0

Resultado esperado:

interface: wg0
  public key: <your-pubkey>
  listening port: 51820

peer: clrU9+AjXQ4GdSEV4NhIWs4uspF76tlemYpE8mZR6z0=
  endpoint: 34.22.248.0:51820
  allowed ips: 10.200.0.0/16
  latest handshake: 18 seconds ago
  transfer: 3.2 KiB received, 4.8 KiB sent
  persistent keepalive: every 25 seconds

Docker (linuxserver/wireguard)

docker exec rela-vpn wg show

Mismo formato que Linux directo.

Criterio de aprobación: latest handshake < 120 segundos + transfer > 0 bytes en ambas direcciones.

Capa 2 — Routing

La ruta hacia la subnet asignada por Rela AI debe pasar por la interfaz WireGuard.

Linux / Router con shell

ip route get 10.200.7.2  # reemplazá por IP dentro de tu subnet asignada

Esperado:

10.200.7.2 dev wg0 src 10.200.7.2 uid 0

La clave: dev wg0 (o rela-vpn según el nombre que le pusiste). Si aparece dev eth0 o similar, la ruta está mal y el tráfico no va por el túnel.

Mikrotik

/ip route print where dst-address=10.200.X.0/24

Debería mostrar una ruta GATEWAY=rela-vpn.

pfSense / OPNsense

Diagnostics → Routes y busca 10.200.X.0/24 — debe apuntar a la interfaz rela_vpn.

Criterio de aprobación: el prefix 10.200.X.0/24 (tu subnet asignada) tiene ruta vía la interfaz WireGuard.

Capa 3 — Conectividad IP (ping)

Desde tu router/gateway, ping a una IP dentro de la subnet asignada por Rela AI:

ping -c 4 10.200.7.2

Esperado: 0% packet loss, RTT típicamente 30–150 ms (dependiendo de tu ubicación geográfica respecto a europe-west1).

Nota: Sólo las IPs "del lado de Rela AI" responden al ping si tenemos un sim ahí (testbed). En producción tu subnet está reservada sólo para tus dispositivos, así que el ping fallará hasta que hayas configurado un PLC o un test peer. La ausencia de ping a 10.200.X.2 no es necesariamente un error en prod.

Cuando sí importa: desde el lado de la planta, ping <IP_del_PLC> (IP interna, NO IP de la VPN) debe funcionar. Si no funciona, el PLC o tu LAN tienen problema — no es la VPN.

Criterio de aprobación: ping al PLC desde el router (LAN local) funciona.

Capa 4 — Puerto TCP

Ahora verificamos que el puerto Modbus (502) del PLC responde:

# Desde el router / gateway, si tiene nc o ncat:
nc -zv <IP_DEL_PLC> 502

# Alternativa con telnet:
telnet <IP_DEL_PLC> 502

Esperado:

Connection to 192.168.1.50 502 port [tcp/*] succeeded!

Si ves Connection refused o No route to host, el problema es en la planta — no en la VPN. Revisá:

• Firewall local de planta entre el router y el PLC.
• El servicio Modbus del PLC está encendido.
• La IP correcta — consultá la configuración de red del PLC.

Criterio de aprobación: nc/telnet al puerto 502 del PLC dice succeeded.

Capa 5 — Lectura Modbus real

Prueba de un read_holding_registers contra el PLC. Hay varias herramientas:

Desde Linux con pymodbus-client (más técnico)

pip install pymodbus
python3 <<EOF
import asyncio
from pymodbus.client import AsyncModbusTcpClient
async def main():
    c = AsyncModbusTcpClient("192.168.1.50", port=502)
    await c.connect()
    r = await c.read_holding_registers(address=0, count=1, device_id=1)
    print("value:", r.registers if hasattr(r, "registers") else r)
    c.close()
asyncio.run(main())
EOF

Esperado: un número (por ejemplo [785] si es la temperatura ×10).

Desde Windows con Modbus Poll (GUI)

1. Instalar Modbus Poll (trial gratuito).
2. Connect → Modbus TCP/IP → IP del PLC, puerto 502, Unit 1.
3. Setup → Read/Write Definition → Holding Register, Address 0, Quantity 1.
4. Debería mostrar el valor en tiempo real.

Desde el Dashboard de Rela AI

Si ya creaste la fuente Modbus apuntando al PLC:

1. Dashboard → Alarmas → Fuentes → tu-fuente.
2. Pulsá Test connection.
3. Se abre un panel con:
   • rtt_ms: latencia de ida y vuelta (debe ser menor a 500 ms).
   • sample_values: tabla con el nombre del registro + valor decodificado.

Criterio de aprobación: lees un valor numérico que cambia con el proceso real (si miras durante 10-30 segundos, debería variar ligeramente si el proceso está activo).

Capa 6 — Pipeline completo en el Dashboard

La última milla: los eventos llegan al inbox.

1. Dashboard → Alarmas → Inbox.
2. A los 1-5 minutos de tener la fuente activa, deberías ver eventos con el nombre de tu registro como event_type (por ejemplo reactor.temperature).
3. El inbox consolida detecciones de la misma fuente bajo el mismo asset; si ves una fila creciendo con count × N, está funcionando.

Criterio de aprobación: eventos con tu event_type aparecen en el inbox.

Troubleshooting Capa 1: el handshake nunca llega

Si Last Handshake = never o RX/TX en 0:

1. Firewall de salida

Tu router debe poder hacer conexión saliente UDP al puerto 51820 hacia la IP pública de nuestro concentrador. Muchos firewalls corporativos bloquean UDP por default.

Check: desde el router, intenta conectar con nc -uvz <ip-concentrador> 51820 (se queda colgado unos segundos y termina). Si el firewall permite, salta al siguiente paso; si bloquea, pedí a IT abrir ese flujo saliente.

2. Clave pública correcta

Un solo caracter perdido en copy-paste rompe el handshake. Verificá que la PublicKey del peer en tu router coincide exactamente con la que muestra el dashboard.

3. NAT cerrando el mapping

Si tu router está detrás de un NAT doble (ISP + corporativo), el mapping UDP puede cerrar antes del próximo handshake. Asegurate que PersistentKeepalive = 25 está activo. Esto fuerza un handshake cada 25s y mantiene el NAT vivo.

4. MTU mismatch

Raro pero posible: si tu conexión tiene MTU menor a 1420, los paquetes WG se fragmentan. En los logs del router podés ver "packet too big".

Fix: bajá el MTU de la interfaz WG a 1380:

• pfSense: VPN → WireGuard → Settings → MTU = 1380
• Linux: ip link set mtu 1380 dev wg0

Troubleshooting Capa 3-4: handshake OK pero no llegás al PLC

1. Forwarding deshabilitado en el router

Tu router debe tener net.ipv4.ip_forward=1 para pasar tráfico entre interfaces.

• Linux: sudo sysctl -w net.ipv4.ip_forward=1 (persistir en /etc/sysctl.conf).
• pfSense: viene habilitado por default.
• Mikrotik: viene habilitado por default.

2. Reglas de firewall LAN

Tu router debe permitir tráfico desde la interfaz WG hacia tu LAN OT.

• pfSense: Firewall → Rules → WireGuard interface. Añadí regla Allow from any to LAN subnet.
• OPNsense: igual.
• Mikrotik: verificá que no haya regla de drop en /ip firewall filter para packets in-interface=rela-vpn.

3. PLC no acepta conexiones fuera de su LAN

Algunos PLCs tienen whitelist interna de IPs. El origen del TCP desde nuestro worker es 10.200.X.2 (la IP asignada en tu subnet VPN). Asegurate que el PLC no bloquea esa IP.

Troubleshooting Capa 5-6: Modbus responde local pero Rela AI no

1. El worker no tiene Direct VPC Egress habilitado

Si tu cuenta acaba de activar conectividad VPN, puede haber un retraso de unos minutos hasta que Cloud Run redeploye. Esperá 5 minutos y reintentá.

2. Deployment mode incorrecto

• Si el PLC está detrás de tu VPN, la fuente debe tener deployment_mode = cloud_direct.
• Si usás rela-ai-edge en vez de VPN, debe ser deployment_mode = edge + asignar edge_gateway_id.

3. Unit ID incorrecto

Verificá en el PLC qué slave ID responde (1 es default pero algunos PLCs vienen con 2 o 255).

4. Data type / byte order

Si la conexión funciona pero el valor se ve absurdo, es problema de decodificación. Ver el troubleshooting en la guía Modbus.

Checklist rápido para imprimir

[ ] wg show muestra latest handshake < 2 min
[ ] ip route get <IP_subnet_asignada> → dev wgX
[ ] ping desde router al PLC local funciona
[ ] nc -zv <PLC_IP> 502 → succeeded
[ ] read_holding_registers desde router devuelve valor real
[ ] Dashboard: Test connection con rtt_ms < 500 + sample_values correctos
[ ] Inbox: eventos con event_type=<nombre_registro> aparecen a los 2 min

Si los 7 checks están ✓, tu túnel está listo para producción. Pasá el testigo al equipo de planta para que empiecen a configurar alarmas y reglas.

Si algún check falla, tenés el rincón exacto que revisar — usá el troubleshooting correspondiente arriba.