Ich habe an zwei Firmenstandorten jeweils zwei DSL-Leitungen. Damit
kann ich zwischen den Standorten zwei VPN-Tunnel aufbauen, die
jeweils 2 MBit haben. Ich möchte die beiden Tunnel jetzt so
zusammenschalten, dass ich bei einer Übertragung 4 MBit erreichen
kann.
Bei der Suche bin ich auf das sogenannte “bonding” gestoßen, mit dem
man Netzwerk-Channel auf Paketebene verbinden kann.
In den Diskussionen findet man zwar ab und zu, dass bonding mit dem
Kernel-Treiber auch für Tunnel- oder ppp Interfaces funktionieren
soll, doch ich erhalte eine Fehlermeldung, wenn ich die tun0 und
tun1 Interfaces der beiden openvpn-Tunnel zum bonding-Interface
hinzufügen möchte:
pc:/home/user# modprobe bonding mode=0 miimon=100
pc:/home/user# ifconfig bond0 hw ether 00:11:22:33:44:55
pc:/home/user# ifconfig bond0 192.168.55.55 up
pc:/home/user# ifenslave bond0 tun0 tun1
Master ‘bond0’, Slave ‘tun0’: Error: Enslave failed
Master ‘bond0’: Error: set hw address failed
Master ‘bond0’, Slave ‘tun1’: Error: Enslave failed
Ist es möglich, mit dem Kernel-bonding die beiden vpn-Tunnel zu
verbinden, oder ist der Treiber ausschließlich für Ethernet-Links?
Gibt es andere Möglichkeiten, wie ich die beiden Tunnel auf
Paketebene verbinden kann?
[1] http://www.linuxhorizon.ro/bonding.html
[2] http://forum.hetzner.de/wbb2/thread.php?threadid=5683
Warum ich nicht früher drauf gekommen bin:
Wenn man nicht die IP-Routing Interfaces tunX nutzt, sondern die tap-Devices,
hat man eine Ethernet-Verbindung, die sich ganz problemlos bonden lässt. Bis
jetzt funktioniert es sehr gut, sogar die Failover-Funktionalität läuft auf
Anhieb. Bei Ausfall einer Leitung muss noch nicht einmal das Download neu
gestartet werden.
Frage: Funktioniert das Bonding auch mit Interfaces, die über verschiedene Geschwindigkeiten verfügen?
Wir haben hier eine ADSL-Leitung mit 6/0,5 MBit/s und eine SDSL mit 1,5 MBit/s.
Ich würde diese gern zusammentun.
Prinzipiell ja. Ich nutze für das Bonding mode 0 (Round-robin Bonding). Damit
werden die Pakete gleichmäßig auf alle Kanäle verteilt. In der einen Richtung
hättest du dann 3 MBit, in der anderen 1 MBit. Viel besser wird es mit mode 0
nicht gehen.
Interessanter könnte mode 5 (Adaptive transmit load balancing) sein. “The
outgoing traffic is distributed according to the current load (computed
relative to the speed) on each slave.” Ob das bei openvpn-Tunneln
funktioniert, weiß ich allerdings nicht. Es könnte Probleme geben, falls der
Bonding-Treiber die Geschwindigkeit nicht ermitteln kann. Ansonsten müssten
man das einfach mal austesten.
Hallo Martin und Alle!
Kann mir mal Jemand bei meinem OpenVPN-Problem, welches ich hier schon beschrieben habe, helfen? Ich hoffe, ich poste hier richtig, bin neu in der Liste…
Danke!
Peter.
Irgendwie ist mein voriges Posting offensichtlich doch nicht richtig angekommen, oder?
Ich hänge es hier nochmal dran…
========================================================
Hallo Martin!
Bräuchte dringend Hilfe zu gebondeten tap-devices! Hab hier in etwa folgende Konfiguration:
|——(WL1a) ))) ((( (WL1b)——|
LR LR
|——(WL2a) ))) ((( (WL2b)——|
LR .. Linux Router
WL .. WLAN Router
Nun versuche ich, über die WL vom LR links zum LR rechts Tunnel zu bauen mit tap-Devices, so wie du das beschrieben hast… Das funzt auch, ich habe auf beiden Seiten zwei tap-devices, jeweils tap0 und tap1. Ich kann die auch bonden (mode=0), hatte aber erwartet, wenn dann eine Leitung durch “Entstromen” eines WL ausfällt, dass dann der Traffic allein über die 2. leitung läuft…Funzt aber nciht, Die Übertragung bricht ab!?!?!? Hier noch paar Eckdaten:
LR links (Auszug):
bond0 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2040 (1.9 Kb) TX bytes:2336 (2.2 Kb)
tap0 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::74c7:95ff:fe74:73bb/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1014 (1014.0 b) TX bytes:1174 (1.1 Kb)
tap1 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::74c7:95ff:fe74:73bb/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1026 (1.0 Kb) TX bytes:1162 (1.1 Kb)
Das gleiche – mit anderen Adressen – auf dem LR rechts.
Was mich bisschen wundert: “ip tunnel” zeigt gar nix! Brauche ich zwangsweise noch ein tun-device???
Schon mal vielen Dank!
Peter.
Hallo Peter,
habe lange nicht ins Forum gesehen, daher erst jetzt die Antwort – aber
vielleicht hilft sie dir ja noch.
Dieses Problem hatte ich auch zuerst. Wenn eine Verbindung abbricht, kommt der
Datenverkehr vollständig zum Erliegen, weil das Bonding-Interface nichts davon
mitbekommt und weiterhin die Daten aufteilt. Folglich kommen 50% der Pakete
nicht an und damit ist keine Datenübertragung möglich.
Ich habe das ganze gelöst, indem ich in die Server-Konfigurationsdateien von
openvpn “keepalive 5 15” und in die Client-Konfigurationsdateien “ping 5” und
“ping-restart 15” eingetragen habe. Damit schickt openvpn selbstständig alle 5
Sekunden ein Paket durch die Leitung. Werden 15 Sekunden keine Pakete
übertragen, wird die Verbindung neu gestartet. Bricht jetzt eine Verbindung
ab, dauert es 15 Sekunden, bis openvpn die Reinitialisierung einleitet und
damit das tap-Device entfernt. In diesen 15 Sekunden ist kein Datenverkehr
möglich. Die meisten Verbindungen werden aber durch den Ausfall von 15
Sekunden nicht abgebrochen. Wenn das tap-Device entfernt ist, nimmt der
Bonding-Treiber die Leitung raus und die Übertragung läuft nur noch über die
andere Leitung.
Jetzt ist noch das Problem, dass das Bonding-Interface den Kanal nicht wieder
automatisch aufnimmt, wenn openvpn die Leitung wieder hergestellt hat und das
tap-Device wieder existiert. Dafür habe ich in alle Konfigurationsdateien
(client und Server) von openvpn “ipchange ./connect1.sh” beim ersten Tunnel
und “ipchange ./connect2.sh” beim zweiten Tunnel eingetragen. Die Skripte
connect1/2.sh sind Bash-Skripte mit folgendem Inhalt:
#!/bin/bash
ifenslave bond0 tap0
bzw.
#!/bin/bash
ifenslave bond0 tap1
Damit werden die tap-Devices automatisch in das Bonding eingebunden, wenn ein
Tunnel von openvpn neu aufgebaut wird.
Ich hoffe das löst dein Problem.
Mit freundlichen Grüßen
Martin Schuster
Hallo Martin,
bondest du eigentlich auf beiden Seiten oder nur auf der Seite des Home Routers?
Viele Grüße
Marcus
Hallo Martin,
mit welcher Software hast Du die Firmennetze verbunden?
Ich möchte 2 Netze mit OpenVPN verbinden, finde aber keine Anleitung hierzu.
mit besten Grüßen,
Zaphod
Hallo,
zum einfachen Verbinden der Netze habe ich OpenVPN genutzt. Eine sehr gute
Anleitung ist das Howto auf der OpenVPN-Seite (http://openvpn.net/howto.html).
Unter Linux (bei mir Debian) ist das Paket schnell installiert, so dass man
gleich mit dem Anlegen der Zertifikate beginnen kann. Für die Konfiguration
habe ich die Konfigurationsbeispiele genutzt, die von OpenVPN mitgeliefert
werden. Es sind dort nahezu keine Änderungen notwendig.
Wenn der Tunnel aufgebaut ist, kannst du über eine Routingtabelle die Subnetze
verbinden. Dazu gibt es im Howto auch schon einige Beispiele.
Mit freundlichen Grüßen
Martin
Hallo Martin,
ich habe bis jetzt gedacht OpenVPN sei nur für Roadwarrior zu Server Verbindungen und so benutze ich es auch.
Da mein englisch ziemlich mies ist, habe ich nur das Nötigste auf openvpn.net gelesen :-(
Aufgrund Deines Hinweises habe ich mir das howto nochmals angeschaut und folgenden Punkt gefunden:
“Including multiple machines on the client side when using a routed VPN (dev tun)”
:-)
Vielen Dank für Deine Auskunft!
Hallo Martin!
Bräuchte dringend Hilfe zu gebondeten tap-devices! Hab hier in etwa folgende Konfiguration:
|——(WL1a) ))) ((( (WL1b)——|
LR LR
|——(WL2a) ))) ((( (WL2b)——|
LR .. Linux Router
WL .. WLAN Router
Nun versuche ich, über die WL vom LR links zum LR rechts Tunnel zu bauen mit tap-Devices, so wie du das beschrieben hast… Das funzt auch, ich habe auf beiden Seiten zwei tap-devices, jeweils tap0 und tap1. Ich kann die auch bonden (mode=0), hatte aber erwartet, wenn dann eine Leitung durch “Entstromen” eines WL ausfällt, dass dann der Traffic allein über die 2. leitung läuft…Funzt aber nciht, Die Übertragung bricht ab!?!?!? Hier noch paar Eckdaten:
LR links (Auszug):
bond0 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2040 (1.9 Kb) TX bytes:2336 (2.2 Kb)
tap0 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::74c7:95ff:fe74:73bb/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1014 (1014.0 b) TX bytes:1174 (1.1 Kb)
tap1 Link encap:Ethernet HWaddr 76:C7:95:74:73:BB
inet addr:192.93.15.100 Bcast:192.93.15.255 Mask:255.255.255.0
inet6 addr: fe80::74c7:95ff:fe74:73bb/64 Scope:Link
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1026 (1.0 Kb) TX bytes:1162 (1.1 Kb)
Das gleiche – mit anderen Adressen – auf dem LR rechts.
Was mich bisschen wundert: “ip tunnel” zeigt gar nix! Brauche ich zwangsweise noch ein tun-device???
Schon mal vielen Dank!
Peter.