Neuanfang: VPN-Beschleunigung jeglicher Art

Technik
61

Hallo,

@DerTrickreiche: Das mit den VLANs gucke ich mir Mal später an.

Ich hab heute nochmal probiert den Offloader direkt via Ubuntu zu realisieren. Fastd läuft, verbindet sich, allerdings bekomme ich immer die komische Fehlermeldung:

Cannot find device "bat0"
Failed to bring up bat0.

Die kriege ich einfach nicht weg, obwohl das bat0-Interface geladen wird:

$ ifconfig
bat0      Link encap:Ethernet  Hardware Adresse 52:6b:28:cb:d7:e0  
inet6-Adresse: fe80::506b:28ff:fecb:d7e0/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
RX-Pakete:14 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:12 Fehler:0 Verloren:66 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0 
RX-Bytes:1116 (1.1 KB)  TX-Bytes:1264 (1.2 KB)

Leider mesht das ganze Ding aber nicht über WAN. Vermutlich muss ich mesh-on-wan nochmal separat irgendwo konfigurieren?

Was mich sehr beunruhigt ist der fakt, dass hier:

$ sudo traceroute6 -i mesh-vpn www.google.de
WARNING: interface is ignored: Operation not permitted
traceroute to www.google.de (2a00:1450:4013:c01::5e) from 2002:5c4d:3e61:0:4066:55e0:c694:5eef, 30 hops max,     24 byte packets
 1  fritz.box (2002:5c4d:3e61:0:3631:c4ff:fe15:4bb6)  0.903 ms  0.477 ms  0.419 ms

Warum zum Geier steht da fritz.box? Mesh-VPN muss die Fritz-Box doch überspringen?

Und was mich auch sehr beunruhight:

Hab ich etwa gerade meine Leitung als Gateway konfiguriert? Wo zum Geier kommen die ganzen Mac-Adressen in der FB her?

Also iwas stimmt da noch nicht.

Frage, muss eigentlich ipv4 und ipv6 forwarding im Kernel aktiviert sein?

Ich hab das jetzt erstmal alles wieder deaktiviert.

Grüße
MPW

62

Kann auf der Gluon-Box/Offloader nicht funktionieren. Grund: mesh-vpn hat keine globale IPv6 Adresse. Du brauchst irgendein Device/Interface was per Router Advertisement globale Adressen und Routing zugewiesen bekommt.

63

Wie kann ich das konfigurieren?

64

Das ist der Grund, warum wir drigend eine „Spielwiesen-Domain“ benötigen.
Solche Aktionen schiessen dann für mindestens Minuten dutzendweise Nodes und Clients aus dem Netz, weil die Routen semi-disfuntional sind, gerade für „nach dem Abschalten der Amok-Config.“

Aber danke, dass Du an der Aktion „Negative Störerhaftungs-Feststellungsklage“ aktiv teilnimmst.

1 „Gefällt mir“
65

Gute Idee. Und wir brauchen mal eine anständige Netzwerkdokumentation.

Welches Interface macht eigentlich was und was muss wie konfiguriert sein?

Es ist iwie bisschen blöd, dass wir zwar 1000ende funktionierender Router haben, aber mir niemand erklären kann, wie ich deren Netzwerkkonfiguration nachbilde :wink:

1 „Gefällt mir“
66

Auf dem Offloader? Ich befürchte gar nicht. Du wirst wohl ein extra Gerät als Client brauchen.

67

Ich denke, dass ich die komplette Netzwerkarchitektur nachstellen kann. Problem ist nur, dass ich noch keine Dokumentation für diese gefunden habe.

Warum sollte ein Rechner sich anders verhalten als ein Router, so rein netzwerktechnisch?

68

Ja klar kann man das!
Alles Wesentliche findet man eigentlich hier und hier.

69

Ich hatte mal folgende Skizze gemacht, um mir selbst einen Überblick zu verschaffen:

ff-router.pdf (9.6 KB)

70

Wieso? Tut er doch gar nicht. Was Du wolltest/willst geht auch mit einem original Gluon Router nicht.

71

Also ich habe das Dienstag mal probiert, kam aber auf keinen grünen Zweig, Setup:

root@tst-x86-gluon:~# cat /etc/rc.local 
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

ifconfig eth1 up
brctl addbr br-eth1
brctl addif br-eth1 eth1
ifconfig br-eth1 up
batctl if add br-eth1
exit 0
root@tst-x86-gluon:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-wan          7fff.5254007286d5       no              eth0
br-eth1         8000.525400caf18b       no              eth1
br-client               7fff.5254007286d5       no              bat0
root@tst-x86-gluon:~# batctl if
br-eth1: active
mesh-vpn: active
root@tst-x86-gluon:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: br-eth1/52:54:00:ca:f1:8b (bat0)]
   de:ad:be:ef:00:00 (104) de:ad:be:ef:07:01 [  mesh-vpn]: 215 - 96MBit/96MBit
=> de:ad:be:ef:04:01 ( 96) de:ad:be:ef:07:01 [  mesh-vpn]: 207 - 48MBit/48MBit
root@tst-x86-gluon:~# batctl tg | wc -l
369
root@tst-x86-gluon:~# batctl tr 40:b0:fa:8c:fa:10
traceroute to 40:b0:fa:8c:fa:10 (12:fe:ed:9c:16:e2), 50 hops max, 20 byte packets
 1: de:ad:be:ef:07:01  31.838 ms  31.571 ms  31.796 ms
 2: de:ad:be:ef:04:01  47.877 ms  47.728 ms  47.335 ms
 3: 12:fe:ed:9c:16:e2  78.032 ms  77.958 ms  78.197 ms

Host-View: 

root@ponder:~# brctl show

bridge name     bridge id               STP enabled     interfaces

br0             8000.00e066afb0e8       no              eth0

vnet0

vnet1

vnet2

br1             8000.00e04c534458       no              eth2

vnet3

ponder:eth2 ist ein USB-Ethernet-Adapter, an dem ich dann einen normalen FFGT-Knoten per blauem Port (Mesh on WAN aktiviert) angeschlossen habe. Jener Knoten tauchte in der Karte dann auch auf, auch funktionierte die IPv4-Adressvergabe an Clients. ponder:eth2 ist der physikalische Port, tst-x86-gluon:eth1 die andere Seite der Bridge in der KVM-Instanz. Aber IPv4-Datenverkehr war „flaky“, und von unserem gw01 konnte ich nicht über die Link-Local-v6-Adresse per SSH auf den Knoten zugreifen.

Wenn ich einen Speedtest versuchte, war bei 5 MBit/sec Schluß – die CPU auf „ponder“ allerdings langweilte sich wie auch die in der VM. Ich fürchte/vermute mal, daß der Knoten hinter der KVM-Gluon-Instanz sich per (Fördervereins-) IPv6 mit den echten GWs verband, somit würde ich Tunnel-in-Tunnel-Konstrukte ausgemessen haben :frowning:

72

Wesentlich schneller kann mein Handy nicht.

73

?

74

@adorfer: Auf welcher Konstruktion beruht die Messung?

Bzgl. virtualisiertem Gluon habe ich heute Mal einen Wiki-Eintrag erstellt: https://freifunk-muenster.de/wiki/doku.php?id=technik:virtualisiertes_gluon

75

Build vom Gluon-Master im Januar 2015, site.conf aus dem github von rheinufer.
Virtualbox unter einem 12er-LTS auf einem billigst möglichen Sandybridge-Celeron.
WR841er via MeshOnWan hinter dem mesh-VPN-Knoten, Handy im AP-Netz des WR841.

76

Hättest du einmal die genaue CPU-Bezeichnung für mich? Möchte Mal die Spezifikationen vergleichen. Vllt. virtualisiert Baytrail einfach wirklich so viel schlechter als SandyBridge.

cat /proc/cpuinfo

Welche Netzwerkkarte ist in VirtualBox eingestellt? PCIneT 100?

/edit: Okay ich hab jetzt auch nochmal mit dem nativen fastd auf Ubuntu rumgespielt. Fazit: Mit fester IP läuft alles bis auf der Knotenname, mit dynamischer IP wird der Offloader benutzt, taucht aber gar nicht auf der Karte auf, da br0 keine ip bekommt und alfred iwie nichts ausgibt. Aber laut cpu-Auslastung wird er trotzdem genutzt. Schaffe jetzt immerhin so bis zu 8 Mbit/s auf J1800. Mehr schafft mein i7 aber gerade auch nicht, irgendwie ist das Netz scheinbar relativ voll hier gerade. Meine DSL-Leitung hat jedenfalls noch Spiel nach oben, muss dann an den Gateways liegen.

Fragen:

  • Wie kann ich Alfred den Knotennamen beibringen?

  • Wie kann ich die IP-Vergabe dynamisch machen, braucht der Knoten überhaupt eine ipv4? Hab schon überlegt den ipv4-Teil wegzulassen, weil die Router ja auch keine ipv4 haben:

    auto lo
    iface lo inet loopback

    auto eth3
    iface eth3 inet dhcp

    auto br0
    iface br0 inet6 dhcp
    bridge_ports none
    bridge_stp no
    netmask 48

    allow-hotplug bat0

    iface bat0 inet6 manual
    pre-up modprobe batman-adv
    post-up ip link set dev bat0 up
    post-up brctl addif br0 bat0
    post-up batctl it 10000
    post-up start-stop-daemon -b --start --exec /usr/sbin/alfred – -i br0 -b bat0;
    post-up start-stop-daemon -b --start --exec /usr/sbin/batadv-vis – -i bat0 -s;

Ich bekomme aber leider keine IP-Adressen auf br0 (das würde ja br-client auf den Routern entsprechen):

br0       Link encap:Ethernet  Hardware Adresse 6a:2c:7a:71:9b:bc  
          inet6-Adresse: fe80::3857:f3ff:fe42:cf0e/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:241 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX-Bytes:0 (0.0 B)  TX-Bytes:78306 (78.3 KB)

Und die ipv6 stimmt auch nicht, unser Adressblock fängt mit 2a03 an.

Vermutung: Der versucht DHCP von der FritzBox zu ziehen und nicht über das MeshVPN.

Routing sieht derzeit so aus:

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth3
0.0.0.0         0.0.0.0         0.0.0.0         U     1038   0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth3
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth3
77

Zweimal default, einmal via eth3 zur Fritte, einmal als Wolke auf br0? v4 wird so nicht gehen, ich vermute, Linux bevorzugt das auf einem Interface direkt erreichbare 0/0 anstelle des 0/0 über einen Extrahop.

78

D.h. jetzt in der Konsequenz?

79

Mehrere unabhängige Routingtabellen, aka policy based routing.

80

Mit festen Adressen lief es doch, ich muss nur an der entsprechenden Stelle sagen, dass er für br0 einen anderen DHCP-Server nehmen soll…