ich versuche schon seit geraumer Zeit eine virtuelle Freifunk-Maschine in unserer vSphere zu betreiben. Leider scheitere ich nun an dem VPN-Tunnel.
Die virtuelle Maschine mesht sich wunderbar mit anderen TP-Link Routern im LAN, allerdings baut sie keinen eigenen Tunnel auf.
Muss ich auf weitere Einstellungen außer network.mesh_wan.auto=1 achten?
Ein Hinweis, der für euch nützlich sein könnte:
Die VM gibt mir auf der Commandline foldenden Text aus: br-wan: received packet on eth1 with own address as source address.
Habt ihr einen Tipp, wie ich das troubleshooten kann?
Das ist die falsche Einstellung für den VPN-Tunnel. Die sollte auf ‚0‘ stehen in deiner Konfiguration. (Damit leitest du lokales Mesch auf das WAN-Interface und somit in dein privates Netz. Das willst du nicht.
Je nach Community musst du Fastd oder den Tunneldigger aktivieren.
uci show|grep enabled
wird die Option anzeigen.
Wichtig ist auch bei VMware den promisken Modus (promiscous mode) oder wie er dort heißt zu aktivieren, weil die MAC der WAN-Schnittstelle bei Gluon wechselt. Wie es genau geht, kann ich nicht sagen. Bin KVM-Nutzer.
Den ‚Promiscous mode‘ hatte ich bereits aktiviert. Die MAC-Adressänderungen waren noch nicht erlaubt. Das habe ich nun nachgezogen und offenbar baut er nun den Tunnel auf.
DAs ist übrigens nicht nur bei VMware-Hosts ein „beliebtes“ Thema, sondern auch bei irgendwelchen Orten an denen Switche mit strikter Port-Security gefahren werden. Wo z.B. selbst an einem eigentlich „offenen“ Port trotzdem zeitgleich nur eine MAC-Adresse zulässig ist… da failed das Gluon auch, weil er während des Bootens noch mit einer anderen MAC unterwegs ist als zu dem Zeitpunkt an dem er dann das MeshVPN-auf dem WAN-Interface hochbringt.
19: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master bat0 state UP qlen 1000
link/ether 12:73:c2:2b:40:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.26/24 brd 192.168.178.255 scope global br-wan
valid_lft forever preferred_lft forever
inet6 fe80::1073:c2ff:fe2b:4000/64 scope link tentative flags 08
valid_lft forever preferred_lft forever
ip r s
default via 192.168.178.1 dev br-wan src 192.168.178.26
192.168.178.0/24 dev br-wan src 192.168.178.26
192.168.178.1 dev br-wan src 192.168.178.26
ping 1.1.1.1
1.1.1.1 ist erreichbar
logread
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.399787] net_ratelimit: 2302 callbacks suppressed
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.400871] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.402385] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.403762] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.405403] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.406823] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.408555] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.410101] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.411506] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.412923] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.414331] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
bridge name bridge id STP enabled interfaces
br-wan 7fff.1273c22b4000 no eth1
br-lan 7fff.000000000000 no
br-mesh_lan 7fff.000000000000 no
br-client 7fff.00505637c2de no bat0
eth0
local-port
batctl if
br-wan: active
primary0: active
mesh-vpn: active
batctl gwl
[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/12:73:c2:2b:40:03 (bat0/00:50:56:37:c2:de BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
zu den Meldungen im logread/syslog: Schaut so aus als ob schlicht bei Dir die Freifunk-Domain defekt wäre.
Irgendwer hat an einem Router einen Loop zwischen batman und clientnetz gebaut und an den Supernodes wird es nicht gefiltert.
siehe auch