Verbindung zum Offloader schlecht

Ingo.S · 16. November 2021 um 11:38

Hallo zusammen

Ich hoffe die Kategorie hier ist OK.

Wir (Die IT der Gemeinde) haben auf unserer Insel Langeoog seit kurzem ein paar Freifunk Router vom FFNW aufgestellt. Wir nutzen dafür Unifi AP AC-Mesh.

Da das ein paar mehr sind bzw. werden könnten, hatte ich gelesen, es wäre Sinnvoll, wenn man bei allen außer 1-2 APs, das Mesh on VPN abschaltet, um den Haupt-Knoten zu entlasten. Deshalb habe ich in unserem Netzwerk ein VLAN gebaut, das auf der WAN Seite die Internetverbindung für die APs zur Verfügung stellt und auf den APs Mesh on WAN aktiviert und nur auf einem das VPN aktiv gelassen.

Da wir evtl auch ein paar User über LAN raus lassen wollen, habe ich dann einen Offloader in einer virtuellen Umgebung installiert und mit dem WAN in das selbe VLAN gehängt, die LAN Seite hat ein weiteres VLAN bekommen.

Jetzt habe ich nur ein merkwürdiges Phänomen festgestellt und finde keinen Ansatzpunkt, wie ich das Problem eingrenzen kann.

Folgendes:
Die APs untereinander bauen über WAN eine 100% stabile Mesh Verbindung auf. Zum Offloader kommt die Verbindung aber irgendwie nicht richtig zustande. Die finden sich zwar, und wenn ich den Offloader einmal neu starte, kommt die Mesh-Verbindung hoch, aber nach kurzer Zeit wird die dann immer schlechter. Ich habe das mal „gescreenshoted“

Vielleicht kann mir von euch jemand einen Tip geben, wie ich das analysieren kann.
Welche Infos braucht ihr dazu?
Infos zum Offloader:

VLAN120 → WAN
VLAN121 → FFNW LAN

OpenWrt 19.07-SNAPSHOT r11371+25-9882a54c48
Gluon Version: v2021.1.1-9-gaf0f3a13 Gluon Release: 20211030
Hardware model: QEMU Standard PC (i440FX + PIIX, 1996) vpn: l2tp
Domain: Aurich

Netzwerk:

root@ffnw-loog-offloader:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
    link/ether 0a:cc:09:a1:1e:85 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
    link/ether ea:50:2f:55:ea:2f brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether fa:4e:48:e8:a5:b0 brd ff:ff:ff:ff:ff:ff
5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether d6:cc:1f:b1:f7:7e brd ff:ff:ff:ff:ff:ff
6: teql0: <NOARP> mtu 1500 qdisc noop state DOWN qlen 100
    link/void 
7: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 0a:cc:09:a1:1e:85 brd ff:ff:ff:ff:ff:ff
    inet6 2a06:e881:2000:4c01:8cc:9ff:fea1:1e85/64 scope global dynamic 
       valid_lft 86299sec preferred_lft 14299sec
    inet6 fd74:fdaa:9dc4:0:8cc:9ff:fea1:1e85/64 scope global dynamic 
       valid_lft 86299sec preferred_lft 14299sec
    inet6 2a0f:b506:ff01:0:8cc:9ff:fea1:1e85/64 scope global dynamic 
       valid_lft 86016sec preferred_lft 14016sec
    inet6 fe80::8cc:9ff:fea1:1e85/64 scope link 
       valid_lft forever preferred_lft forever
8: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ea:50:2f:55:ea:2f brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.82/24 brd 192.168.20.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fe80::e850:2fff:fe55:ea2f/64 scope link 
       valid_lft forever preferred_lft forever
9: local-port@local-node: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
    link/ether 0a:cc:09:a1:1e:85 brd ff:ff:ff:ff:ff:ff
10: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
    inet6 fd74:fdaa:9dc4::127/128 scope global deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::1441:95ff:fe40:f7dc/64 scope link 
       valid_lft forever preferred_lft forever
11: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UNKNOWN qlen 1000
    link/ether 0a:cc:09:a1:1e:85 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::8cc:9ff:fea1:1e85/64 scope link 
       valid_lft forever preferred_lft forever
12: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN qlen 1000
    link/ether 92:14:8c:04:46:73 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9014:8cff:fe04:4673/64 scope link 
       valid_lft forever preferred_lft forever
13: vx_mesh_wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc noqueue master bat0 state UNKNOWN qlen 1000
    link/ether 92:14:8c:04:46:70 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9014:8cff:fe04:4670/64 scope link 
       valid_lft forever preferred_lft forever
22: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
    link/ether 92:14:8c:04:46:77 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9014:8cff:fe04:4677/64 scope link 
       valid_lft forever preferred_lft forever

wusel · 19. November 2021 um 00:02

Moin,

ein paar Anmerkungen und Fragen, leider keine Lösung für Dein Problem:

Also »eigentlich« kenne ich das Setup eher so, daß man entweder a) eine »Freifunk-VM« mit VPN on WAN und Mesh on LAN aufsetzt, und die AC-Mesh unter Gluon nutzen Mesh on WAN statt VPN on WAN oder b) besagte »Freifunk-VM« mit VPN on WAN und Freifunk on LAN nutzt, die AC-Mesh laufen dann vorzugsweise mit OEM-FW (was auch die rechtlichen Hürden bei 5 GHz galant umschifft). WAN und LAN der VM gehen effektiv in unterschiedliche VLANs, WAN offensichtlich in eines mit Internet-Zugang, LAN ist ein »Freifunk-VLAN«, in dem sonst noch die WANs der APs stecken.

Hintergrund: x86/x64-CPUs sind in der Regel deutlich performanter darin, Pakete über batman ins VPN zu schieben als jeder embeddes SoC.

Dein Netzwerksetup habe ich aus der Beschreibung nicht so ganz verstanden, es sind AC-Mesh mit Mesh on WAN und VPN on WAN im gleichen VLAN?

Ingo.S · 19. November 2021 um 07:12

Moin Wusel

Auch Fragen können einen näher zur Lösung bringen. Erstmal Danke.

Wenn ich das richtig interpretiert habe, ist es nicht möglich, LAN Clients ins FF Netzwerk zu bringen, wenn auf der LAN Schnittstelle des Zugangspunktes Mesh on LAN aktiv ist, da Mesh Netz und FF Netz nicht auf der gleichen Schnittstelle sein können.

Ich werde mal versuchen, die Netzstruktur irgendwie grafisch darzustellen. Netzstrukturen zu beschreiben ist wirklich schwer.

Ingo.S · 19. November 2021 um 08:03

So, ich habe gemalt.

So sollte die Struktur des Netzwerkes eigentlich aussehen. Unsere interne LAN Seite ist stark vereinfacht, aber die hat ja auch mit dem FF Netz nichts zu tun.

Meiner Meinung nach sollte die Struktur, so wie ich sie aufgezeichnet habe, eigentlich funktionieren. Das Problem wird vermutlich sein, dass die Struktur in der Realität anders aussieht als ich vermute, weil ich irgendwo einen Fehler gemacht habe.

wusel · 20. November 2021 um 01:22

Danke für die Grafik. Mit Mesh-on-VPN (via WAN) und Mesh-on-WAN parallel habe ich nicht wirklich Erfahrung (i. d. R. mache ich Mesh-on-?AN über ein dediziertes Interface, welches in einem dedizierten VLAN endet; also Knoten 1 Mesh-on-VPN (via WAN) und Mesh-on-LAN ins VLAN, Knoten 2-n Mesh-on-WAN ohne VPN); da das hier per VXLAN enkapsuliert wird, sollte das eigentlich gehen. Allerdings mag das auch Grund für die Probleme sein; ich kenne (== nutze) nur Unicast VTEPs, d. h. ich konfiguriere auf jedem Endpunkt die anderen. Gluon müßte bei Mesh-on-WAN-over-VXLAN auf Broadcast setzen, vielleicht tut das mit Deinem Virtualisierungs-Setup (Proxmox? VMware?) nicht/es fehlen Settings? Weil:

Das klingt so, als ob es ›nur‹ mit dem virtualisierten Gluon hakt, daher würde ich, mit VXLAN als einem Stichwort, in der Richtung gucken.

Ingo.S · 25. November 2021 um 11:12

Gluon müßte bei Mesh-on-WAN-over-VXLAN auf Broadcast setzen, vielleicht tut das mit Deinem Virtualisierungs-Setup (Proxmox? VMware?) nicht/es fehlen Settings?

Der Hypervisor ist ein Proxmox, richtig erkannt.
Also die VLANs sind im Hypervisor auf der Bridge konfiguriert, das funktioniert bei allen VMs eigentlich reibungslos. Die Gluon VM hat daher „keine Ahnung“, dass sich bei den WAN/LAN Interfaces um verschiedene VLANs handelt.
Evtl könnte es noch sein, dass die Bridge des Hosts, unabhängig vom VLAN TAG, alle Pakete an die VM durchlässt. Sowas hatten wir mal bei einem DHCP Server, der dann fleißig, trotz DHCP Relay durch die Firewall, versucht hat, direkt auf eth0 auf die Requests zu antworten
Es könnte ja dann vielleicht sein, dass die Gluon-VM die Broadcasts der APs empfängt, aber auf dem falschen Interface antwortet. Das werde ich mal untersuchen.
Gluon ist leider ziemliches Neuland für mich, es ist alles Andere als leicht, sich da zurecht zu finden.

Das klingt so, als ob es ›nur‹ mit dem virtualisierten Gluon hakt, daher würde ich, mit VXLAN als einem Stichwort, in der Richtung gucken.

Ja, das denke ich auch. Und: Sobald die Gluon VM läuft, wird das Freifunk Netz über die APs quasi unbrauchbar langsam, bzw. komplett Offline. Irgendwas geht dann wohl mit dem Routing schief. Ich hab leider noch nicht raus, wie das Routing im Freifunk Netz eigentlich funktioniert.