Integración externa - Red Unify

¡Gracias @mutmut por las capturas, me ayudan mucho!

Los clientes conectados del widget son los clientes WireGuard del servidor: en tu caso, la UX de Nantes y la UDR de Lieja, conectados como clientes WireGuard a la UDR7. No son los clientes Wi-Fi o Ethernet de los puntos de acceso. Tus dos servidores « WireGuard Nantes » y « WireGuard Liege » se ven bien; es el conteo de sus clientes lo que no funciona.

  • Primer widget : en sus ajustes, es el dispositivo de la pasarela UDR7 el que está seleccionado, no uno de los dos dispositivos « VPN WireGuard ». El widget mostraba entonces el primer servidor encontrado, Nantes. Con la 1.8.1, indica claramente que el dispositivo seleccionado no es un servidor VPN. Elige « VPN WireGuard : WireGuard Nantes » o « … Liege » y estará bien.
  • 0 clientes conectados : buscaba los clientes WireGuard en la lista de clientes de la consola, y tu consola no los pone allí. La documentación de Ubiquiti no dice dónde los guarda. La 1.8.1 añade por tanto una acción Diagnóstico VPN en la página de la integración. Interroga los pocos lugares posibles y solo devuelve nombres de campos, números y códigos HTTP: ninguna dirección, ninguna clave, nada personal. ¿Podrías lanzarla mientras Nantes está conectado y pegar el resultado aquí? Así sabré dónde leer tus clientes.

Actualiza desde Gladys :slightly_smiling_face:

Actualización a 1.8.1.
Ocurre todo lo contrario: UDR7 es el servidor, UX y UDR son los clientes, pero los widgets muestran lo contrario:


Para UDR y UX, son exactamente las mismas capturas que antes.

Para el diagnóstico VPN:

Servidores WireGuard: 2; clientes activos (stat/sta): 41
claves stat/sta sobre VPN: last_uplink_remote_port
#1 habilitado, subred configurada; en subred: 0, mismo network_id: 0
  claves networkconf: _id, dhcpd_dns_enabled, dhcpd_start, dhcpd_stop, dhcpd_wins_enabled, enabled, external_id, firewall_zone_id, interface_mtu_enabled, ip_subnet, ipv6_subnet, local_port, mss_clamp, mss_clamp_ipv6, name, purpose, setting_preference, site_id, vpn_binding_mode, vpn_client_configuration_remote_ip_override_enabled, vpn_type, wireguard_id, wireguard_interface, wireguard_interface_binding_mode_ip_version, wireguard_local_wan_ip, x_wireguard_private_key
  /api/s/{site}/stat/remoteuservpn: 1 elemento(s): assoc_time, id, interface, last_seen, network_id, peer_id, remote_ip, rx_bytes, rx_packets, rx_rate, site_id, tunnel_ip, tx_bytes, tx_packets, tx_rate, up, uptime, user, vpn_type
  /v2/api/site/{site}/wireguard/<id>/users: 1 elemento(s): _id, allowed_ips, interface_ip, interface_ipv6, name, network_id, public_key
  /v2/api/site/{site}/wireguard/<id>/clients: string
  /v2/api/site/{site}/vpn/connections: objeto: connections
  /v2/api/site/{site}/clients/active: 41 elemento(s): anomalies, assoc_time, authorized, blocked, display_name, fingerprint, first_seen, fixed_ip, gw_mac, hostname, id, ip, ipv6_address, is_allowed_in_visual_programming, is_guest, is_wired, last_seen, last_uplink_mac, last_uplink_name, last_uplink_remote_port, latest_assoc_time, local_dns_record, local_dns_record_enabled, mac, model_name, name, network_id, network_members_group_ids, network_name, noted, oui, rx_bytes, rx_bytes-r, rx_packets, site_id, status, sw_port, tags, tx_bytes, tx_bytes-r, tx_packets, type, unifi_device, uplink_mac, uptime, use_fixedip, user_id, usergroup_id, virtual_network_override_enabled, virtual_network_override_id, wired_rate_mbps
  /integration/v1/sites/<site>/clients?limit=200: 41 elemento(s): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId
#2 habilitado, subred configurada; en subred: 0, mismo network_id: 0
  claves networkconf: _id, dhcpd_dns_enabled, dhcpd_start, dhcpd_stop, dhcpd_wins_enabled, enabled, external_id, firewall_zone_id, interface_mtu_enabled, ip_subnet, ipv6_subnet, local_port, mss_clamp, mss_clamp_ipv6, name, purpose, setting_preference, site_id, vpn_binding_mode, vpn_client_configuration_remote_ip_override_enabled, vpn_type, wireguard_id, wireguard_interface, wireguard_interface_binding_mode_ip_version, wireguard_local_wan_ip, x_wireguard_private_key
  /api/s/{site}/stat/remoteuservpn: 1 elemento(s): assoc_time, id, interface, last_seen, network_id, peer_id, remote_ip, rx_bytes, rx_packets, rx_rate, site_id, tunnel_ip, tx_bytes, tx_packets, tx_rate, up, uptime, user, vpn_type
  /v2/api/site/{site}/wireguard/<id>/users: 1 elemento(s): _id, allowed_ips, interface_ip, interface_ipv6, name, network_id, public_key
  /v2/api/site/{site}/wireguard/<id>/clients: string
  /v2/api/site/{site}/vpn/connections: objeto: connections
  /v2/api/site/{site}/clients/active: 41 elemento(s): anomalies, assoc_time, authorized, blocked, display_name, fingerprint, first_seen, fixed_ip, gw_mac, hostname, id, ip, ipv6_address, is_allowed_in_visual_programming, is_guest, is_wired, last_seen, last_uplink_mac, last_uplink_name, last_uplink_remote_port, latest_assoc_time, local_dns_record, local_dns_record_enabled, mac, model_name, name, network_id, network_members_group_ids, network_name, noted, oui, rx_bytes, rx_bytes-r, rx_packets, site_id, status, sw_port, tags, tx_bytes, tx_bytes-r, tx_packets, type, unifi_device, uplink_mac, uptime, use_fixedip, user_id, usergroup_id, virtual_network_override_enabled, virtual_network_override_id, wired_rate_mbps
  /integration/v1/sites/<site>/clients?limit=200: 41 elemento(s): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId

¡Muchas gracias @mutmut, tu diagnóstico era exactamente lo que se necesitaba!

Muestra que tu consola agrupa las conexiones WireGuard en una lista aparte, y no con otros clientes. Esto se ha corregido en la 1.8.2: los clientes conectados se leen en las conexiones VPN activas del UDR7, y se nombran como en UniFi. En tu caso, el servidor « WireGuard Nantes » debería mostrar 1 cliente conectado (el UX), con los datos intercambiados, y « WireGuard Liege » 0 mientras el UDR esté apagado. Los disparadores « Cliente VPN conectado/desconectado » también se activan para ellos.

Para los widgets, entiendo la confusión: los dos dispositivos « VPN WireGuard » están en tu UDR7. Son los dos servidores WireGuard que has creado allí, uno por sitio. No representan el UX ni el UDR. El dispositivo « udr7 » de la lista es la pasarela en sí, no un servidor VPN, de ahí el mensaje del primer widget. Por lo tanto:

  • widget « VPN WireGuard: WireGuard Nantes » → ¿Está conectado Nantes?;
  • widget « VPN WireGuard: WireGuard Liege » → ¿Está conectado Lieja?.

Actualiza desde Gladys y dime si Nantes aparece bien :slightly_smiling_face:

¡Bingo, entendí la diferencia, gracias!

Queda perfecto:


Vamos, si me atreviera, también te pediría el ancho de banda en tiempo real (o casi) además del tráfico (si es posible) :wink:
También creo que podemos pasar a Go cuando supera los 1000 Mo y To cuando supera los 1000 Go.
Por cierto, ¿es un contador diario o acumulativo?

@mutmut ¡Genial, gracias por el comentario! ^^

Ya está hecho en 1.8.3: a partir de 1000 MB el tráfico pasa a GB, y a partir de 1000 GB a TB. Actualicen desde Gladys.

Para tu pregunta: no es diario, es el acumulado de la conexión en curso del cliente, tal como lo muestra la consola.

El ancho de banda en tiempo real, lo anoto: la consola no lo muestra directamente para el VPN, habría que calcularlo entre dos mediciones. Lo reviso.

¡1.8.3 es lo mejor!
image

He descubierto otro pequeño problema… mira mi captura de pantalla. En las actividades, la integración informa cada minuto sobre la presencia de todos mis dispositivos relevantes. En cuanto al contenido, es correcto, pero es completamente innecesario, ya que satura el registro de actividades. (No es un registro del sistema, sino algo útil). Sería más lógico que solo se registrara en el registro de actividades si no se había detectado presencia con anterioridad. De lo contrario, tengo tantos registros en el registro de actividades como dispositivos que debo supervisar por minuto. No es ideal :slight_smile:

Me he dado cuenta de un pequeño problema: si uso una escena para establecer el estado de presencia de una persona en función del estado del dispositivo, tengo un retraso, y un retraso no documentado.

¿Por qué? Porque la presencia de esta integración parece tener un valor fijo de 5 minutos antes de marcar un dispositivo como ausente. Es decir, mi escena no debe verificar si un dispositivo ha sido marcado como ausente durante 5 minutos, porque entonces terminaría en 10 minutos. 5 minutos de retraso en la detección de la integración de la red Unifi hasta que se marca como ausente, y luego 5 minutos de retraso hasta que la escena indica que este dispositivo ha tenido el estado de ausente.

Mi sugerencia: hacer configurable el tiempo hasta que un dispositivo se marque como ausente (por ejemplo, al salir de la red WiFi). :slight_smile:

@stefanbauer ¡Gracias por los dos comentarios!

Retraso hasta „ausente“: Ya es configurable, en la configuración bajo „Retraso de ausencia (s)“ (por defecto 120 s). Con 1.8.4 (actualización a través de Gladys) ahora también funciona 0: antes, 0 se tomaba en silencio como 120 s. Sin embargo, queda un residuo en el lado de UniFi: la consola solo informa un teléfono como desconectado cuando ya no lo ve (inactividad de WLAN), lo que puede tardar unos minutos, sobre lo cual no tengo influencia.

Registro de actividades: La presencia se envía intencionalmente cada minuto, porque la acción de escena de Gladys, que verifica la presencia de un usuario, solo mira el momento del último valor. El escáner de red integrado de Gladys hace lo mismo. Veré cómo se puede resolver esto de manera más limpia y me pondré en contacto.

Gracias @guim31

Sobre el primer punto. Ah, tenemos un problema similar en las escenas para la acción « Verificar presencia de usuarios ». Si allí se escribe 0 en el retraso, tampoco da error, se guarda sin decir nada, pero como 10 min. Creo que es un error en el núcleo.

¡Gracias @stefanbauer!

Registro de actividades: Con 1.9.0 (actualización a través de Gladys) hay una opción en la configuración: „Enviar presencia cada minuto“ (activada por defecto, como antes). Si la desactivas, la integración solo envía cambios: el registro de actividades se mantiene limpio, pero la acción de escena „Verificar presencia de usuarios“ ya no funcionará para estos dispositivos.

0 → 10 min.: Tienes razón, es un error en el núcleo, concretamente en el editor de escenas: el servidor acepta 0, pero al volver a abrir la escena, el editor reemplaza 0 silenciosamente por 10, y al guardar de nuevo, se queda en 10. Lo comunicaré al equipo de Gladys, indicando la línea de código.