3 Tube im bridge modus

Hi! Habe schon versucht auf der mailingliste, hier nochmals: möchte einen openwrt router auf dem ein tunnel terminiert über lte verbinden. Habe einen 3 tube, hat ein gbit port, sollte bis 150 mbit/s gehen. Lte ist mit 50 - 60 mbit/s verfügbar. Im „normalen“ modus kriege ich so max. 15 mbit/s rüber. Hat dann am ethernetport eine fixe private ip über welche die fixe route zum tunnelserver führt, dann geht alles. Nun hat das ding auch einen bridge mode wo irgend eine private ip am port auftaucht und via dhcp geroutet werden kann. Durchsatz 35-45 mbit/s (Durchsatz ist mit 40mbit/s gebucht). Leider flappt der tunnel bei dieser config geht 10 sec, dann 20 sekunden nicht, geht wieder … Hauptproblem: es wird eine Default route ueber ebendiese ip gesetzt und mein tunnel funktioniert nur intermittierend. Gibt es da scripte, wo man das automatisiert aktualisieren kann ? Ich denke mir aktuelle gateway ip abfragen , fixed route für tunnel setzen, default gateway löschen und neu via olsr definieren lassen.

OpenWRT hat unter /etc/hotplug.d/iface diverse Skripte, die man ausführen kann, wenn ifup oder ifdown-Ereignisse auftreten.

Eventuell kann Du da eines schreiben. Ich bin nur nicht sicher, ob sie auch zuverlässig aufgerufen werden. Folgende Variablen stehen zur Verfügung $ACTION ifup,ifdown, $INTERFACE OpenWRT-Interface-Name, $DEVICE Systemname des Interfaces und IFUPDATE_ADDRESSES =1, wenn sich die Adresse ändert.

Es gibt aber auch ein Verzeichnis dhcp in /etc/hotplug.d …

Danke, ist ein wenig verwirrend, gibt auch was in /lib/netifd/ , werde testen…
Ich hoffe, dass meine Überlegung richtig ist: mal schauen, ob ich das default gateway per dhcp verhindern kann, eine Hostroute auf den Tunnelserver legen kann und olsr das default gateway definieren lasse … wenn das manuell funktioniert mal als script anlegen.

immerhin hab ich schon gesehen, dass der openwrt router nicht der Flaschenhals ist, Durchsatz durch den router auf das modem im bridge modus war > 40 Mbit/s (=lte limit des Vertrages).

Eine Alternative könntest Du noch direkt in OpenVPN versuchen:

–route-gateway gw|’dhcp’

Specify a default gateway gw for use with –route. If dhcp is specified as the parameter, the gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN.

Davor:
–route network/IP [netmask] [gateway] [metric]

Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.This option is intended as a convenience proxy for the route (8) shell command, while at the same time providing portable semantics across OpenVPN’s platform space.

netmask default — 255.255.255.255

gateway default — taken from –route-gateway or the second parameter to –ifconfig when –dev tun is specified.

metric default — taken from –route-metric otherwise 0.

The default can be specified by leaving an option blank or setting it to “default”.

The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:

vpn_gateway — The remote VPN endpoint address (derived either from –route-gateway or the second parameter to –ifconfig when –dev tun is specified).

net_gateway — The pre-existing IP default gateway, read from the routing table (not supported on all OSes).

remote_host — The –remote address if OpenVPN is being run in client mode, and is undefined in server mode.

Keine Ahnung, wie man es konkret macht, aber vielleicht findest Du es ja heraus.

vielleicht mittels Zweizeiler?

route-gateway ‚dhcp‘
route 78.41.115.16

So, jetzt habe ich eine Woche zeit mich mit dem Problem zu beschäftigen.
Jetzt habe ich vorab folgenden Test gemacht:
Openwrt Router am Gigabit Port des 3-Tube mit Netz 192.158.100.x verbinden
Tunnel steht NAT auf 192.168.103.x
Switch an Port 2 192.1168.103.1
Switch an Port 3 192.168.100.100 (also WAN direkt)

Wenn ich über Port 2 gehe, geht die Verbindung über den VPN Tunnel, ca. 14 Mbit/s
Wenn ich über Port 3 gehe, geht die Verbindung über Drei.at, ca. 40 Mbit/s

40 Mbit/s ist die max. gebuchte Geschwindigkeit. Kann es sein, dass ein Openwrt einfach soviel CPU Zeit verbraucht wird, dass der Tunnel nicht schneller gehen kann? (ca. CPU Load geht bei RTR-Test über 1).
Wenn das so ist, könnte ich mir die umkonfiguration mit bridendem LTE Modem sparen

Wenn Du mir zur Kontrolle sagst, um welchen Tunnelport es geht, kann ich nachschauen, ob wir noch etwas tunen können. Das Indiz, dass der Flaschenhals der Router wäre, ist nicht von der Hand zu weisen. Eventuell probiere ich demnächst wireguard, aber da muss ich mir noch Gedanken machen, wie wir das IP-Adress-sparend hinbekommen.

Hi,
Nach dem Test mit auth=none hab ich den Tunnel nicht mehr zum Laufen gebracht. Wenn ich folgende config aktiviere, wird tap07 angelegt, aber es wird vom server nichts empfangen:

„verb 0
remote 78.41.115.16 5007
proto udp
dev-type tap
port 5007
dev tap07
tun-mtu 1500
auth none
cipher none
secret /etc/openvpn/funkfeuer.secret
sndbuf 524288
rcvbuf 524288
secret /etc/openvpn/funkfeuer.secret
up /etc/openvpn/scripts/funkfeuer-ifupdown.sh
down /etc/openvpn/scripts/funkfeuer-ifupdown.sh
script-security 2“

ifconfig:
tap07 Link encap:Ethernet HWaddr XXXXXXXXXX
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:1482 (1.4 KiB)

Ich schaue es mir gleich nocheinmal an. Ist Dein Tunnelclient gerade aktiv? Ändere nichts, ich versuche ihn dann „einzufangen“.

Danke paßt jetzt. Habe beim speed ein wenig experimentiert, und zwar mit send receive buffer
(theoretische Bandbreite des links 40 Mbit/s down 10 Mbit/s up.) Nicht berücksichtigt ist, dass natürlich Schwankungen bei der Auslastung sein könnten)

send receive ping down up
16384 16384 34 11 11 Mbit/s
32768 32768 34 15 9.5
262144 65000 30 27 10
131072 131072 34 30 9.5
262144 131072 32 24 9.5
256000 256000 37 25 10
524288 131072 36 26 10
524288 262144 36 25 10
524288 524288 34 20 11
1048576 1048576 33 20 11

1/3 bis 1/2 Tradeoff sollten realistisch sein. Bekommst Du über den Links ohne Tunnel die volle Bandbreite? Netznutzungsklasse?

Wie im vorigen Posting geschrieben, gibst Du keinen Wert für die Fragmentgröße an. Das wäre die Größe, die ein Datenpaket unter OpenVPN haben darf, u.z. ohne UDP-Header (8 Byte) und ohne IP-Header (20 Byte). Rein zufällig ist das bei Pings derselbe Wert (MTU-28). Wenn Du also den Tunnelserver mittels ping -s 1472 -Mdo -c1 78.41.115.16 erreichen kannst (Antwort kommt, OK), dann ist Deine Link-MTU 1500 und OpenVPN kann fragment 1472 nützen. Ist es weniger, müssen wir den Wert auf beiden Seiten setzen, wenn wir mit der tun-mtu von 1500 stabil arbeiten wollen. Für diesen Wert gilt auch die oben getroffene Performance-Prognose.

Ja, wenn ich ohne Tunnel fahre kriege ich mit rtr-Netztest Spitzen bis 50 Mbit/s (das ist fast das Maximum was auf LTE Seite dort geht, mit Mobilphone gemessen 50-60 Mbit/s), pendelt sich dann auf die gebuchten 40 Mbit/s ein. Der ursprünglich erwähnte bridge mode scheint nicht wirklich in Kombination mit Openwrt was zu bringen. Jetzt habe ich tagsüber immerhin Datenraten um die 20 bis 25 Mbit/s, in der Nacht gehen regelmäßig >30 Mbit/s.
Openwrt versteht leider die Option -Mdo nicht, ohne kann ich bis -s 1492 gehen, darüber kommt nichts zurück. Ich hab auf meiner Seite im Moment link-mtu 1472 eingestellt, aber kein fragment (im /etc/openvpn/funkfeuer.conf wäre das dann „fragment 0“?).
PS: wenn ich den opnevpn tunnel auch in luci anlege (so wie in der wiki mit option enable ‚1‘ und option config „path“ und so, steht immer ein anderer Port in der Liste (ich glaube es war 1198 oder so), obwohl im config-file die richtige Portnummer drinnen steht. Hab jetzt dort auch die Portnummer angegeben, damit es optisch richtig ausschaut).

iputils-ping ist das Paket, wo Ping mit der Option „-M“ drinnen ist.
Alternativ kann auch tracepath: iputils-tracepath helfen.

Wenn Du über LTE drinnen bist, sollte die MTU eigentlich wegen PPP 1496 betragen.
Es gibt Router, die Pakete reorganisieren, sodass Du auf dem LAN-Interface doch 1500 herausbekommst - doch WWAN-seitig ergibt das Fragmente, die die Performance drücken.

Wenn Deine MTU 1492 wäre (was bei PPPoE oder PPTP der Fall wäre), dann musst Du für die OpenVPN-Fragmente diese Differenz auf 1500 abziehen. (1500 - 1492) - 28 = 1464.

Das muss man auf beiden Seiten einstellen.