Am 14.01.2015 um 18:56 schrieb Ronny Seffner:

Hi pulux,

ich bin verwirrt.

Du schreibst "redundant". Ich interpretiere, beide Server sollen das Selbe machen z.B. zwecks Ausfallsicherheit.

richtig

Aber Du erläuterst Cli1 sieht Server2 und Cli2 sieht Server1, Ziel sei, Cli1 kann, mit Cli2 reden.

Ja in den erläuterten Beispiel zum Zeitpunk t1. Zum Zeitpunkt t2 kann es aber auch sein ein Server down ist und die Client die Verbindung zum anderen Server aufbauen. Es sind aber auch nicht immer alle Clients online, so dass z.B. zum Zeitpunkt t3, wieder beide Server online sind und sich ein neuer Client zudem zuletzt wieder online gegangenen Server verbindet. Setzt endlich soll solange wenigstens ein Server online ist die Kommunikation von jeden Client zu jeden anderen Client möglich sein und das ganz egal zu welchem Server sich der Client verbunden hat.

Für Letzteres braucht es "Sicht" zwischen Server1 und Server2, das ist weniger VPN-Konfigurationshexerei als Netzwerkrouting.

Ja richtig, nur wie sage ich es openvpn unter den dynamischen Randbedingungen?

Ich meine mich erinnern zu können eine Konfiguration gesehen zu haben wo beide Server über einen vpn-Tunnel mit einander "sprechen" und die Client-Pakete passend weiterleiten.

Wenn dann ein Server ausfällt brechen auch die Client Verbindungen zusammen und die Clients verbinden sich mit dem anderen Server. Das ist einfach in derClient Konfig über mehrere remote Einträge zu erreichen. Wie aber sieht die Konfig auf dem Server für das Client-Paket-Routing aus?

Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8

---

Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd

Nach einigen Suchen habi ich folgendes gefunden:

activ-avtiv OpenVPN-Server

Es werden zwei Server mit Linux, openvpn und python benötigt. Die Clients tauschen ihre Daten über das VPN-Netz 10.100.100.0/24 aus. Die Server tauschen ihre Informationen über das VPN-Netz 10.100.200.0/24 aus.

Auf den Servern werden jeweils zwei VPN-Schnittstellen erstellt, tun0 für die Daten und tun1 für das Management.

#ServerA #/etc/openvpn/vpnA-data.conf server 10.100.100.0 255.255.255.0 ifconfig 10.100.100.1 10.100.100.2 push "route 10.100.100.0 255.255.255.0" push "route 10.200.200.0 255.255.255.0" dev tun proto udp user nobody client-to-client persist-key persist-tun dh keys/dh1024.pem ca keys/ca.crt cert keys/vpnsrvA-1.crt key keys/vpnsrvA-1.key comp-lzo verb 3 keepalive 10 60 client-config-dir ccd management tunnel 5656 /etc/openvpn/pass

#ServerA #/etc/openvpn/vpnA-m.conf server 10.100.200.0 255.255.255.0 ifconfig 10.100.200.1 10.100.200.2 #push "route 10.100.100.0 255.255.255.0" push "route 10.200.200.0 255.255.255.0" dev tun proto udp port 11940 user nobody persist-key persist-tun dh keys/dh1024.pem ca keys/ca.crt cert keys/vpnsrvA-1.crt key keys/vpnsrvA-1.key comp-lzo verb 3 keepalive 10 60 client-config-dir ccd management tunnel 5657 /etc/openvpn/pass

#ServerA #/etc/openvpn/vpnA-conf.ini vpnsrvA mgmt_interface = tun1 data_interface = tun0 remote_mgmt_ip = 10.200.200.6 remote_data_ip = 10.100.100.101 openvpn_mgmt_pass_file = /etc/openvpn/pass openvpn_mgmt_port = 5656 cube_routed_port = 5657

#ServerB #/etc/openvpn/vpnB-data.conf mode server tls-server ifconfig 10.100.100.101 10.100.100.102 ifconfig-pool 10.100.100.4 10.100.100.251 route 10.100.100.0 255.255.255.0 push "route 10.100.100.0 255.255.255.0" push "route 10.200.200.0 255.255.255.0" dev tun proto udp client-to-client user nobody persist-key persist-tun dh keys/dh1024.pem ca keys/ca.crt cert keys/vpnsrvB-1.crt key keys/vpnsrvB-1.key comp-lzo verb 3 keepalive 10 60 client-config-dir ccd management tunnel 5656 /etc/openvpn/pass

#ServerB #/etc/openvpn/vpnB-m.conf client remote IP-von-ServerA dev tun proto udp port 11940 user nobody persist-key persist-tun dh keys/dh1024.pem ca keys/ca.crt cert keys/client-0.crt key keys/client-0.key comp-lzo management tunnel 5657 /etc/openvpn/pass

#ServerB #/etc/openvpn/vpnB-conf.ini mgmt_interface = tun1 data_interface = tun0 remote_mgmt_ip = 10.200.200.1 remote_data_ip = 10.100.100.1 openvpn_mgmt_pass_file = /etc/openvpn/pass openvpn_mgmt_port = 5656 cube_routed_port = 5657

Mit diesen Dateien und dem Python-Script von: https://github.com/aguynamedben/cube-routed.git kann das System in Betrieb genommen werden. Dafür werden die VPN-Netze mit /etc/init.d/openvpn start gestartet und dann das Script mit der ini-Datei aufgerufen.

#Client #/etc/openvpn/client-1.conf client remote IP-von-ServerA remote IP-von-ServerB dev tun proto udp user nobody persist-key persist-tun keepalive 10 60 comp-lzo ca keys/ca.crt cert keys/client-1.crt key keys/client-1.key ns-cert-type server

Was haltet ihr davon? geht es evtl. noch einfacher?

Am 15.01.2015 um 07:31 schrieb pulux:

Danke für den Hinweis, das werde ich testen. Am 15.01.2015 um 04:37 schrieb Andre Klärner:

...

Hi pulux,

On Wed 14.01.2015 17:28:41, pulux wrote:

...

ich bin auf der Suche nach einer openvpn Konfiguration mit zwei openvpn-Servern und n-Clients. Der Datenverkehr soll via client_to_client erfolgen.

Ich habe eine ähnliche Konfiguration am laufen. Einer meiner Server bei mir zuhause unterhält eine ständige VPN-Verbindung in das Firmen-Netz eines meiner Kunden. Jetzt kann ich mich aus meinem Netz zu jedem Host im entfernten Netz meines Kunden verbinden, und "aus meinem Netz" schließt auch die Maschinen ein, die via VPN verbunden sind. Das alles funktioniert auch in der umgekehrten Richtung, also alle Clients des Firmen-Netzes können auf Ressourcen meines Netzes inkl. der VPN-Clients zugreifen.

Ich habe also, wenn ich VPN-Client zu VPN-Client kommuniziere, drei VPN-Verbindungen involviert. Dieses Setup hat sich bewährt, auch wenn die Client to Client - Kommunikation selten benötigt wird.

Ich habe auf dem Firmen-VPN (das via TUN überträgt) folgende Config:

# tun0.conf server 10.0.1.0 255.255.255.0 ifconfig-pool-persist ip-pool.txt port 1194

# client-specific config-options client-config-dir clients-config

# routes advertised by clients route 172.16.0.0 255.255.255.0

push "route 172.16.0.0 255.255.255.0" push "route 192.168.142.0 255.255.255.0"

client-to-client

ping 30 ping-restart 120 persist-tun persist-key

# clients-config/hive.ak-online.be iroute 172.16.0.0 255.255.255.0

## EOF

Mittels client-config-dir habe ich meinem Server eine zusätzliche Konfiguration gepusht, und auf dem Firmen-Server internes Routing ergänzt, sobald der Client (mein Server) online ist.

Mein Server hat auf seiner eigenen Seite noch ein paar Routen gesetzt, die für alle VPN-Clients des Firmen-Servers gelten (192.168.142.0/24 ist das Firmen-LAN).

Mein eigenes VPN ist ein TAP-VPN, das am internen (virtuellen) Switch hängt, und direkt vom DHCP-Server auf IP-Ebene versorgt wird. Damit spare ich mir eine Menge Konfiguration, denn das Routing funktioniert für alle lokalen und remote Clients identisch, da mein Server das Standard-Gateway ist.

Angenommen deine beiden Server stehen in recht zentraler Lage (z.B. zwei Datacenter des Hosters deiner Wahl) und sollen VPN-technisch sich identisch "anfühlen", inkl. der vergebenen Client-IP, würde ich die folgende Konfiguration vorschlagen:

• Leg auf jedem Server eine Bridge an (brctl)
• Konfiguriere auf beiden Servern einen DHCP-Server, der die lokale Bridge befüttert, und sich mit dem jeweils anderen abspricht, welche IPs er vergibt (also ein großes Subnet/"statische" IPs via

MAC-Adresse, aber ein Server funktioniert als Fail-Over des anderen (https://www.madboa.com/geek/dhcp-failover/) )

• Konfiguriere einen Server mit dem VPN (TAP-based) und lasse das Interface der lokalen Bridge hinzufügen.
• Konfiguriere den anderen Server mit einem VPN-Client der den ersten Server kontaktiert und einem VPN-Server der analog zum ersten

arbeitet. Dabei sollten beide TAP-Interfaces der lokalen Bridge hinzugefügt werden.

• Anschließend kannst du die Clients konfigurieren, mit dynamischen

IPs und einem dynamischen DNS kommst du wahrscheinlich am leichtesten, denn die MAC-Adressen von tun und tap-Interfaces kann man leider nicht auf einen bestimmten Wert festlegen (AFAIK, es kann sein das es inzwischen geht), alternativ kann man DHCP natürlich noch über Hostnamen statisch fixieren.

An sich sollte diese Konfiguration recht gut ein zentrales Setup spiegeln, wo beide VPN-Server an einem internen Netz hängen, das DHCP, DNS und Routing abnimmt, und beide Server direkt in das interne Netz patchen.

Wenn du noch Fragen hast, immer her damit, ich mag Spielerei mit Netzwerken ;)

Grüße, Andre

---

Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd

---

Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd

Hallo Ottmar,

On Fri, Jan 16, 2015 at 19:23:40 +0100, Ottmar-Schmidt@web.de wrote:

1. Hat schonmal jemand auf Fritzboxen mit custom Betriebssystem

experimentiert ??

Ja, auf einer Fritzbox 7240 habe ich letztes Jahr Freetz installiert. Das war kurz nachdem AVM die Sicherheitsluecke im Webinterface gefixed hatte und die Freetz-Entwickler auf die gefixte Version als neue Basisfirmware umgestiegen sind.

2. hat schonmal jemand hinter der 7490 ne alte Box wireless als Repeater

betrierben ?? Wenn Ja welche ???

Nein, weil ich keine 7490 habe und auch keinen Wireless Repeater brauche. Tatsaechlich habe ich die Wireless-Funktion meiner Box abgeschaltet.

4 Ich hab mal Freez runter geladen Freez verlangt aber eine bestimmte Firmwareversion der 7170 die bnatürlich so nciht mehr zum Herunterladen da ist und jedes mal neu herunter geladen werden muss.wie kann man sich da ggf helfen

Genau das ist das grundsaetzliche Problem bei Freetz. Es handelt sich dabei ja "nur" um ein Remastering einer bestimmten Firmwareversion. Ist diese bei AVM nicht mehr verfuegbar, kann man nichts machen.

Es soll $LEUTE geben, die inoffiziell diese aelteren Versionen zum Download anbieten. Da es bei meiner Freetz-Installation die Firmwareversion noch bei AVM gab, habe ich diese Alternativdownloads nicht verfolgt.

Die Fritzbox 7170 ist nicht gerade ueppig mit Ressourcen ausgestattet, selbst wenn man Freetz darauf zum Laufen bringt, geht wahrscheinlich nicht sehr viel.

5. hat jemand eRdahrungen mit Freez

Meine Erfahrungen sind begrenzt. Ich verwende Freetz hauptsaechlich dafuer, per ssh auf meine Fritzbox zu kommen und ggf. von dort aus per WakeOnLAN einen Rechner hinter der Box aufzuwecken.

6. Kennt jemand Alternativen zu freez ??

Auf sehr wenigen Fritzbox-Modellen soll wohl auch OpenWRT laufen.

7. Wie nennt sich der Routungstandrd der 7490 ??

Keine Ahnung.

8. Kennt jemand noch alternative Lösungswege ??

Kabel verlegen? :)

Gruss, Chris