Externe Integration - Unify-Netzwerk

Entwicklung
61

Danke @mutmut für die Screenshots, das hilft mir sehr!

Die verbundenen Clients des Widgets sind die WireGuard-Clients des Servers: bei dir die UX von Nantes und die UDR von Lüttich, die als WireGuard-Clients mit der UDR7 verbunden sind. Es sind nicht die Wi-Fi- oder Ethernet-Clients der Access Points. Deine beiden Server „WireGuard Nantes“ und „WireGuard Lüttich“ werden korrekt erkannt; es ist die Zählung ihrer Clients, die nicht funktioniert.

  • Erstes Widget: In seinen Einstellungen ist das Gerät des Gateways UDR7 ausgewählt, nicht eines der beiden Geräte „VPN WireGuard“. Das Widget zeigte dann den ersten gefundenen Server, Nantes. Mit der 1.8.1 gibt es klar an, dass das ausgewählte Gerät kein VPN-Server ist. Wähle „VPN WireGuard: WireGuard Nantes“ oder „… Lüttich“ und es wird funktionieren.
  • 0 verbundene Clients: Ich suchte die WireGuard-Clients in der Liste der Clients der Konsole, und deine Konsole zeigt sie dort nicht an. Die Ubiquiti-Dokumentation sagt nicht, wo sie sie speichert. Die 1.8.1 fügt daher eine Aktion VPN-Diagnose auf der Integrationsseite hinzu. Sie fragt die wenigen möglichen Orte ab und gibt nur Feldnamen, Zahlen und HTTP-Codes zurück: keine Adressen, keine Schlüssel, nichts Persönliches. Kannst du sie starten, während Nantes verbunden ist, und das Ergebnis hier einfügen? Dann weiß ich, wo ich deine Clients lesen kann.

Aktualisiere von Gladys aus :slightly_smiling_face:

62

Aktualisierung auf 1.8.1.
Es passiert genau das Gegenteil: UDR7 ist der Server, UX und UDR sind die Clients, aber die Widgets zeigen das Gegenteil:

image
image675×133 23 KB

Für UDR und UX sind es genau die gleichen Screenshots wie zuvor.

Für die VPN-Diagnose:

WireGuard-Server: 2; aktive Clients (stat/sta): 41
stat/sta-Schlüssel zum VPN: last_uplink_remote_port
#1 aktiviert, Subnetz gesetzt; im Subnetz: 0, gleiche network_id: 0
  networkconf-Schlüssel: _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 Element(e): 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 Element(e): _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: object: connections
  /v2/api/site/{site}/clients/active: 41 Element(e): 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 Element(e): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId
#2 aktiviert, Subnetz gesetzt; im Subnetz: 0, gleiche network_id: 0
  networkconf-Schlüssel: _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 Element(e): 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 Element(e): _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: object: connections
  /v2/api/site/{site}/clients/active: 41 Element(e): 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 Element(e): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId
63

Vielen Dank @mutmut, deine Diagnose war genau das Richtige!

Sie zeigt, dass deine Konsole die WireGuard-Verbindungen in einer separaten Liste anzeigt und nicht mit den anderen Clients. Das ist in der 1.8.2 behoben: Die verbundenen Clients werden aus den aktiven VPN-Verbindungen des UDR7 gelesen und wie in UniFi benannt. In deinem Fall sollte der Server „WireGuard Nantes“ 1 verbundenen Client (den UX) anzeigen, mit den ausgetauschten Daten, und „WireGuard Liege“ 0, solange der UDR ausgeschaltet ist. Die Trigger „VPN-Client verbunden/verbunden“ werden auch für sie ausgelöst.

Bei den Widgets verstehe ich die Verwirrung: Die beiden Geräte „VPN WireGuard“ befinden sich beide auf deinem UDR7. Es handelt sich um die beiden WireGuard-Server, die du dort erstellt hast, einen pro Standort. Sie stellen weder den UX noch den UDR dar. Das Gerät „udr7“ in der Liste ist das Gateway selbst, kein VPN-Server, daher die Nachricht des ersten Widgets. Also:

  • Widget „VPN WireGuard: WireGuard Nantes“ → ist Nantes verbunden;
  • Widget „VPN WireGuard: WireGuard Liege“ → ist Lüttich verbunden.

Aktualisiere über Gladys und sag mir, ob Nantes korrekt angezeigt wird :slightly_smiling_face:

64

Bingo, ich habe den Unterschied verstanden, danke!

Das ist perfekt:

image
image662×377 38.8 KB

Also, wenn ich mich trauen würde, würde ich dich auch nach der Echtzeitdurchsatz (oder fast Echtzeit) zusätzlich zum Verkehr fragen (wenn es möglich ist) :wink:
Ich denke auch, dass wir auf Go wechseln können, wenn es 1000 Mo überschreitet und auf To, wenn es 1000 Go überschreitet.
Übrigens, ist das ein Tageszähler oder ein kumulativer Zähler?

65

@mutmut Top, danke für das Feedback ^^

Es ist in 1.8.3 erledigt: Ab 1000 MB wird der Verkehr in GB umgewandelt, und ab 1000 GB in TB. Bitte aktualisieren Sie über Gladys.

Zu deiner Frage: Es ist nicht täglich, sondern die Summe der aktuellen Verbindung des Clients, wie die Konsole sie anzeigt.

Den Live-Durchsatz notiere ich mir: Die Konsole gibt ihn nicht direkt für das VPN an, er müsste zwischen zwei Messungen berechnet werden. Ich schaue mir das an.

66

1.8.3 ist der Hammer!
image

67

Ich habe noch ein kleines Problem entdeckt… siehe meinen Screenshot. In den Aktivitäten meldet die Integration jede einzelne Minute für all meine Geräte die relevant sind, die Anwesenheit. Inhaltlich ist das sicherlich korrekt, aber es ist halt komplett unnötig, denn das knallt mir das Aktivitäten Log zu. (Ist ja kein Systemlog, sondern etwas brauchbares). Es wäre daher sicherlich sinnvoll, wenn das nur dann als Aktivitäten Log geschrieben wird, wenn es vorher keine Anwesenheit erkannt hat. Ansonsten hab ich pro Minute mind die Anzahl der zu überwachenden Geräte an Logs im Aktivitätenlog. Nicht ideal :slight_smile:

image
image1920×1209 152 KB

68

Mir ist noch ein kleines Problem aufgefallen: Nutze ich eine Szene um auf Basis des Geräte Status den Anwesenheitsstatus einer Person zun setzen habe ich ein Delay und zwar ein nicht dokumentierten Delay.

Warum? Weil das Presence dieser Integration scheinbar einen fixen Wert von 5 Min hat, bis er ein Gerät auf abwesend setzt. D.h. meine Szene darf nicht prüfen ob ein Gerät seit 5 Min abwesend markiert ist, denn das endet sonst in 10 Min. 5 Min Verzug Erkennung Unifi Network Integration bis als abwesend markiert ist, und dann 5 Min Verzug bis die Szene sagt, dass dieses Gerät jetzt den Status abwesend hatte.

Mein Vorschlag: Die Zeit, bis ein Gerät als abwesend markiert wird (z.b. beim Verlassen des Wlans) einstellbar machen. :slight_smile:

69

@stefanbauer Danke für die zwei Rückmeldungen!

Verzögerung bis „abwesend“: Die ist schon einstellbar, in der Konfiguration unter „Abwesenheitsverzögerung (s)“ (Standard 120 s). Mit 1.8.4 (Update über Gladys) funktioniert jetzt auch 0: Vorher wurde 0 stillschweigend als 120 s genommen. Ein Rest bleibt aber auf Seiten von UniFi: Die Konsole meldet ein Handy erst als getrennt, wenn sie es selbst nicht mehr sieht (WLAN-Inaktivität), das kann ein paar Minuten dauern, darauf habe ich keinen Einfluss.

Aktivitäten-Log: Die Anwesenheit wird absichtlich jede Minute neu gesendet, weil die Szenen-Aktion von Gladys, die die Anwesenheit eines Benutzers prüft, nur auf den Zeitpunkt des letzten Werts schaut. Der eingebaute Netzwerkscanner von Gladys macht es genauso. Ich schaue, wie man das sauberer lösen kann, und melde mich.

70

Danke dir @guim31

Zum ersten Punkt. Ah, ein ähnliches Problem haben wir in den Szenen für die Aktion « Anwesenheit von Benutzern prüfen ». Wenn man dort bei der Verzögerung 0 reinschreibt, kommt ebenfalls kein Fehler, wird stillschweigend gespeichert, aber als 10 Min. Ist eigentlich ein Bug im Core, denke ich.

71

Danke @stefanbauer!

Aktivitätenprotokoll: Mit 1.9.0 (Update über Gladys) gibt es in der Konfiguration die Option „Anwesenheit jede Minute erneut senden“ (standardmäßig an, wie bisher). Schaltest du sie aus, sendet die Integration nur noch Änderungen: Das Aktivitätenprotokoll bleibt sauber, aber die Szenen-Aktion „Anwesenheit von Benutzern überprüfen“ funktioniert dann für diese Geräte nicht mehr.

0 → 10 Min.: Du hast recht, das ist ein Fehler im Core, und zwar im Szenen-Editor: Der Server nimmt 0 an, aber beim erneuten Öffnen der Szene ersetzt der Editor 0 still durch 10, und beim nächsten Speichern bleibt 10. Ich gebe das an das Gladys-Team weiter, mit der Stelle im Code.