On Thursday, 26 January 2023 18:33:20 CET Enrico Meinel wrote:
# ###################################################################################### # ip -v4 route default via 10.204.48.2 dev wlp0s26u1u4i2 proto dhcp src 10.204.48.183 metric 20600 10.204.48.0/20 dev wlp0s26u1u4i2 proto kernel scope link src 10.204.48.183 metric 600 # ###################################################################################### # ip -v6 route :1 dev lo proto kernel metric 256 pref medium 2a03:2260:200f:102::/64 dev wlp0s26u1u4i2 proto ra metric 600 pref medium fd01:fd59:0:2200::/64 dev wlp0s26u1u4i2 proto ra metric 600 pref medium fe80::/64 dev wlp0s26u1u4i2 proto kernel metric 1024 pref medium default via fe80::ba:7aff:fedf:102 dev wlp0s26u1u4i2 proto ra metric 20600 pref medium # ######################################################################################
Also hier sieht es so aus als waere bei IPv4+IPv6 der VPN01 ausgewaehlt. Man koennte jetzt mittels `batctl n` schauen ob mesh-vpn anzeigt, dass man auf VPN01 mittels fastd verbunden ist (02:12:7b:00:01:02). Aber da du vpn04 anpingen kannst, haette ich jetzt darauf getippt, dass es ein Problem auf dem VPN-Server waere. Wobei auch dieser Traffic nicht direkt zwischen unseren Servern ausgetauscht wird, sondern auch ueber Freifunk-Rheinland geht.
Uebrigens der Test mit dem IPv6 ist scheinbar nicht soooo gut gewaehlt. Vielleicht macht 2a02:2e0:3fe:1001:302:: mehr Sinn
Und du koenntest halt auch mal traceroute nach 8.8.8.8 bzw. 2a02:2e0:3fe:1001:302:: anschauen. Hier nur mal als Vergleich (wenn es funktioniert ueber VPN01 + ffv_tr):
Host Loss% Snt Last Avg Best Wrst StDev 1. 10.204.48.2 0.0% 11 26.1 37.4 24.7 87.8 19.2 2. 185.66.194.0 0.0% 10 50.6 45.0 35.6 72.2 11.4 3. 80.81.192.108 0.0% 10 40.2 46.1 40.2 65.4 8.9 4. 108.170.252.1 0.0% 10 59.2 56.4 46.6 92.3 14.4 5. 142.250.214.193 0.0% 10 46.8 47.9 44.7 60.5 4.6 6. 8.8.8.8 0.0% 10 45.3 74.2 44.6 214.4 52.6
Host Loss% Snt Last Avg Best Wrst StDev 1. 2a03:2260:200f:102::1 0.0% 12 28.1 29.3 24.7 53.5 8.6 2. 2a03:2260::1 0.0% 12 41.8 44.0 39.2 62.1 6.3 3. (waiting for reply) 4. (waiting for reply) 5. 2a02:2e0:12:34::2 0.0% 11 50.7 61.6 50.0 94.0 14.9 6. 2a02:2e0:3fe:0:c::1 0.0% 11 60.6 62.1 46.7 101.7 16.5 7. 2a02:2e0:3fe:1001:302:: 0.0% 11 69.0 55.3 48.0 73.3 10.0
On Thursday, 26 January 2023 18:33:20 CET Enrico Meinel wrote:
Ich habe jetzt die aktuelle experimental per sysupgrade nochmal drauf geschoben ohne einer Datenübernahme. Mal sehen was wird. Ich teste dann die Tage nochmal. Gibt es evtl. irgendwelche Sachen, welche man auf dem Knoten ausführen kann?
Fuer diesen Fall nicht so viel, da der Traffic einfach nur in den Tunnel zum VPN gebridged wird (oder halt zum naechsten Knoten im Mesh). Man kann halt mal schauen ob der Tunnel korrekt funktioniert. Vielleicht mal mit tcpdump auf mesh-vpn nutzen um ein PCap zu schreiben (am besten direkt ueber Ethernet schreiben: `ssh root@2a03:2260:200f:302:4e13:65ff:fe00:16c0 tcpdump -ni mesh-vpn -w- > test.pcap` .Wireshark kann die diversen Header auch parsen.
Da hatte ich ping und nslookup probiert, aber auch da ging kein Routing durch, bzw. war das auch wie auf dem Client ohne erfolg.
Ich habe gerade beir mir lokal mal einen Knoten auf VPN01 und ffv_tr umgestellt - um zu sehen ob ich das Verhalten nachvollziehen kann. Leider sehe ich da keine Probleme bei mir. Ich schreibe gerade selber ueber diese Verbindung.
Gruesse, Sven