Box2Box mit OpenVPN: Routingprobleme

[AlGates]

Hi Leute,

es tut mir leid, dass ich einen weiteren Thread zu OpenVPN und Box2Box eröffne, aber die bisherigen sind mittlerweile so verschachtelt und unüberschaubar, dass ich mich darin einfach nicht mehr zurechtfinde, zumal ich zwar viele Fantasien, aber leider noch wenig Ahnung von OpenVPN und Co. habe.

Mein Problem sieht folgendermaßen aus:
Ich habe folgendes:

• FB 7170 (Server-Box; IP: 192.168.188.1)
• FB 7050 (Client-Box; IP: 192.168.189.1)
• Rechnernetzwerk hinter beiden Boxen
• OpenVPN läuft bereits mit Zertifikaten

Nach langem Probieren können sich die Boxen nun gegenseitig pingen, aber ich kann die Rechner dahinter nicht pingen, ebensowenig wie ich von den Rechnern dahinter die Gegenbox pingen kann.
Soweit ich das verstanden habe, könnte man eine Server-Bridge verwenden, um dieses Problem zu beseitigen, jedoch traue ich mich da noch nicht ganz ran.
Ich poste daher erstmal meine vorhandenen Config-Dateien:
SERVER-CONFIG:

dev tap
dev-node /var/tmp/tun
mode server
tls-server
proto tcp-server
port 1194
tun-mtu 1500
ca /var/tmp/ca.crt
cert /var/tmp/fritzbox.crt
key /var/tmp/secret.key
dh /var/tmp/dh2048.pem
auth SHA1
cipher AES-256-CBC
server 192.168.200.0 255.255.255.0
client-to-client
ifconfig-pool-persist ipp.txt
float
keepalive 10 60
verb 4
mssfix
route 192.168.189.0 255.255.255.0
push "route 192.168.188.0 255.255.255.0"
daemon

CLIENT-CONFIG:

remote xxx 
dev tap
dev-node /var/tmp/tun
proto tcp-client
tls-client
ns-cert-type server
ca /var/tmp/ca.crt
cert /var/tmp/fritz.crt
key /var/tmp/secret.key
auth SHA1
cipher AES-256-CBC
port 1194
ping 15
ping-restart 120
resolv-retry 60
tun-mtu 1500
mssfix
persist-tun
persist-key
verb 4
pull
push "route 192.168.189.0 255.255.255.0"

Welche Möglichkeiten bestehen, um alle Rechner in beiden Netzwerken zu erreichen, ohne jeden einzelnen per OVPN connecten zu lassen?
Was müsste ich an welcher Box machen?

Ich danke euch schonmal für eure Antworten.

Alex

 

[MaxMuster]

Hallo,

wie sieht denn deine Routingtabelle auf dem Client aus? Ist darin das Netz 192.168.188.0 255.255.255.0 enthalten?
Zum zweiten: Zwischen zwei Routern ist ein Bridging, wie du es mit den tap Devices machst nur in sehr wenigen Ausnahmefällen sinnvoll, das stheht auch in den vorhandenen Threads und besonders auch im Wiki und auf der OpenVPN-Seite (wenn die die Posts zu unübersichtlich sind, liegt das auch daran, dass manche nich so viel lesen wollen und lieber 'nen eigenen Thread eröffnen ;-)).
Ich würde dir eher zu Tunnel-Interfaces tun raten. Dazu gibt es auch eine Masse an Configs, die man quasi "Abschreiben" kann, und die Problematik, mit Routing und Bridging eine Verbindung aufzubauen entfällt (ich verweise mal einfach auf diesen hier )...

Jörg

 

[AlGates]

Hallo,

im Client ist die Route zum 188er Netzwerk drin:

192.168.188.0 192.168.200.1 255.255.255.0 UG 0 0 0 tap0

Dass ich nicht alles lesen wollte, stimmt so nicht. Es gibt da einen 7-Seiten-Thread (29.04.29 und openvpn), den ich von vorne bis hinten gelesen habe und nur dank ihm habe ich überhaupt mein OpenVPN so zum Laufen gebracht, wie es jetzt funktioniert. Allerdings stellt bei jedem 3. Post irgendjemand eine ganz neue Frage und will sein Netzwerk wieder anders aufbauen als das, was der Vorgänger hatte und bisher habe ich noch nichts gefunden, was so läuft, wie ich das möchte.
Ich habe zudem das Problem, dass die beiden FBoxen an zwei Standorten 120km entfernt stehen. Wenn ich von einem Standort an dem anderen bastele und sich beim Reboot die eine FB aufhängt (was nur allzu oft passiert), dann muss ich wieder ewig telefonieren, bis sich jemand bemüht, hinzulaufen und das Ding neuzustarten. Von daher wäre es mir lieber, wenn ich zuerst wüsste, wie es funktioniert und ich das dann auf einmal eintragen kann.

Den Link von dir kenne ich, zumal ich ganz oben auf der Seite selbst gepostet hatte. ;-)

dev tun
dev-node /var/tmp/tun

##########################################
# Server-Einstellungen
tls-server
ifconfig 192.168.200.1 192.168.200.2
# IP-Adresse der 7050 und des Client

Dieser Teil in deinem Link stört mich etwas - und das hatte ich vergessen zu erwähnen - da ich mehrere Clients auf die FB verbinden lassen möchte. So wie ich den Code verstehe, bekommen die beiden FBoxen eine IP und die anderen direkt verbundenen Clients keine mehr.
Oder kann man dann immer noch den Befehl

ifconfig 192.168.200.1 255.255.255.0
ifconfig-pool-persist ipp.txt

verwenden?
Reicht das tun-Device denn für SMB-Freigaben? Oder ist das ein nicht unterstütztes Protokoll von TUN?

Im Prinzip habe ich eine ähnliche Situation wie "hanuta" im von dir verlinkten Thread (hatte damals ja auch dort mitgeantwortet), aber sein Problem verliert sich, nachdem einige weitere dort posten und es bei ihm so halb funktioniert (von der einen Seite geht's, von der anderen nicht), nachdem er auf tun umsteigt.

Soweit ich das verstanden habe, ist Bridging sinnvoll, um zwei gleiche Subnetze miteinander zu verbinden. Das wäre eigentlich kein Problem, da ich dazu nur die eine Box auch in ein 188er Netzwerk verschieben müsste und den DHCP der beiden Boxen so einstellen müsste, dass sich die vergebenen IPs nicht überschneiden.
Das hatte ich auch mal versucht, allerdings führte wohl ein falscher Eintrag in einer Config dazu, dass beide Netzwerke zusammenbrachen, sobald die ClientBox sich auf die ServerBox verbunden hatte, sodass ich davon vorerst die Finger lassen wollte, bis ich das ganze verstanden habe.

Ist tun oder tap&bridging nun am sinnvollsten für meine Zwecke?

 

[MaxMuster]

Hi,

nimms nicht persönlich, war höchstens zum ganz kleinen Teil "gegen" dich ;-) (jetzt weiß ich auch deinen Namen wieder zuzuordnen)!


Zum Thema: In der 2-er Version ist OpenVPN (laut der OpenVPN-Seite) in der Lage, mehrere Clients über ein Tunnelinterface zu bedienen (Hierzu z.B.: "Why does OpenVPN's "ifconfig-pool" option use a /30 subnet (4 private IP addresses per client) when used in TUN mode?" auf dieser Seite).

Für deine Anwendung würde ich vorschlagen (Als Vorschlag, das habe ich noch nicht getestet):

server 192.168.200.0 255.255.255.0
Was wohl "ausgeschrieben" bedeutet:

 mode server
 tls-server

 if dev tun:
   ifconfig 10.8.0.1 10.8.0.2 
   ifconfig-pool 10.8.0.4 10.8.0.251
   route 10.8.0.0 255.255.255.0
   if client-to-client:
     push "route 10.8.0.0 255.255.255.0"
   else
     push "route 10.8.0.1"

 if dev tap:
   ifconfig 10.8.0.1 255.255.255.0
   ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
   push "route-gateway 10.8.0.1"

Die Frage Tunnel/Brücke macht nur dann Sinn, sie mit "Brücke" zu beantworten, wenn die LANs an den Standorten in einem Bereich liegen (Also das Netz 192.168.0.0 255.255.255.0 ist an allen Orten vorhanden, es ist im Bereich 192.168.0.1 - 20 am Standort A, 192.168.0.21 - 50 in B usw...)

Der Nachteil einer Routinglösung (egal ob über tun oder tap) ist, dass ohne Weiteres keine "Windows Namensauflösung" funktioniert. Dafür wäre ein WINS-Dienst nötig (ich weiß gar nicht, ob man sowas als "Teil-Samba" auf eine Box bringen könnte, wäre im Falle von "nein" vielleicht mal eine Anregung). Alternativ muss man mit IP-Adressen handeln oder lokale Dateien mit den Namen pflegen)

Zum Thema Testen würde ich immer vorschlagen/raten, das ganze einfach mal in eine Config zu schreiben und mit (ein paar) PCs ausprobieren. Dann ist die Chance ziemlich groß, dass das auch auf der "gaaanz weit-weit-weg-en" Box funktioniert...

Jörg

 

[s.panzer]

Hallo AlGates,

auch ich habe lange probiert und viel überlegt.

Für mich war wichtig dass später weitere Fritzboxen mit ihren Netzen dazukommen können, auch wollte ich nicht nur ip-Pakete übertragen.
Es sollte auch mit einem Wol-Paket ein Rechner gestartet werden können.

Also war die "Brücke" das richtige: tap

Um nicht alle ip-Adressen in den verschiedenen Netzen zukennen ist hinter jeder Fritzbox ein anderes Netz.

Idealerweise ist der Server gestartet und übergibt nachdem Verbinden mit einem Client sein Netz und das Gateway (ist die VPN-Adresse des Servers) :
push "route-gateway 10.0.0.1"
push "route 192.168.125.0 255.255.255.0"

Auch macht er Routen auf:

route ip-Adresse subnet gateway

route 192.168.122.0 255.255.255.0 10.0.0.2
bedeutet hinter der Fritzbox 10.0.0.2 ist das Netz ....122.0

route 192.168.123.0 255.255.255.0 10.0.0.3
bedeutet hinter der Fritzbox 10.0.0.3 ist das Netz .....123......


Damit werden alle routings im Server erledigt.
Die Client dürfen kein Routing haben.
Der Server darf auch keine IP-Adresse an die Clients vergeben.
Die IP-Adresse muß im Client fest eingestellt sein.
Client dürfen untereinander kommunizieren.

hier die config des Servers:

proto udp
port 1194
dev tap
ca.....
cert....
key.....
mode server
tls-server
dh.....
tls-auth /tmp/flash/static.key 0
ifconfig-pool 10.0.0.2 10.0.0.251
ifconfig 10.0.0.1 255.255.255.0
push "route-gateway 10.0.0.1"
push "route 192.168.125.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix
daemon
verb 3
cipher BF-CBC
route 192.168.122.0 255.255.255.0 10.0.0.2
comp-lzo
keepalive 10 120
status /var/log/openvpn.log


client.config

proto udp
port 1194
dev tap
ca.....
cert.....
key.....
tls-client
ns-cert-type server
tls-auth /tmp/flash/static.key 1
pull
remote my.homeip.net
nobind
ifconfig 10.0.0.2 255.255.255.0
tun-mtu 1500
mssfix
daemon
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log


So sollte es funktionieren.

Melde Dich mal ob es klappt!

Gruß

s.panzer

PS: Ich benutze den openVPN des DS-mod.
Um die Änderungen einzubringen, habe ich die Datei openvpn-lzo_conf aus dem Verzeichnis /var/mod/etc/default.openvpn-lzo in das Verzeichnis /tmp/flash kopiert und die Änderungen direkt eingegeben.
Das Script sucht zuerst im Verzeichnis /tmp/flash nach der speziellen conf Datei.

Im Server: an der Stelle: if [ "$OPENVPN_LZO_REMOTE_NET" ]; then
echo "route $OPENVPN_LZO_REMOTE_NET 10.0.0.2"

und weitere Routen zu den Client-Netzen direkt:

echo "route 192.168.123.0 255.255.255.0 10.0.0.3"

 

[MaxMuster]

Hallo zusammen,
da muss ich doch auch wieder meinen Senf zu ablassen ;-):

Die Brücke ist optimal für den "Road-Warrior", der von unterwegs mit seinem einzelnen Client in das heimische LAN will. Für das von dir wohl angedachte "Site-to-Site" VPN wird "normalerweise" der Tunnel benutzt. Dafür Bridging zu benutzen sollte wohl überlegt und begründet sein! Das ist natürlich in erster Linie von deinen LANs abhängig. Je größer die sind, um so weniger sinnvoll wird das Bridging, denn es erzeugt Overhead auf der Leitung und natürlich in den beteiligten Geräten (Fritzboxen).
BTW:In der vorgeschlagenen Variante (lieber s.panzer, hör doch mal gerade weg ;-)) ist sie zumindest suboptimal (wenn ich schon meine Netze auf Schicht 2 verbinde, warum dann verschiedene Schicht 3 Adressbereiche und den Routingaufwand?).

Es sollte auch mit einem Wol-Paket ein Rechner gestartet werden können.

Na klar, alle "nicht-IP" Protokolle, die du über das VPN übertragen willst, benötigen auch eine besondere Betrachtung. Aber WOL wäre z.B. für mich kein Grund (da es sowohl die Möglichkeit des "directed Broadcasts" gibt, der stressfrei über einen IP-Tunnel geht, oder aber auch mit WoL im ds-mod möglich ist).

Wenn du natürlich auf die "Windows-Namensauflösung" nicht verzichten willst/kannst (wie gesagt, mit IPs ist SMB auch mit TUN problemlos möglich), ist TAP eine Option, solange sich die Netzgrößen "im Rahmen" halten...

Grundsätzlich kannst du das ganze natürlich machen wie du willst und vielleicht brauchst du ja auch direkte Ethernetverbindug. Schau dir aber bitte zumindest vorher nochmal das FAQ ab hier und das hier an.

Jörg

 

[AlGates]

Also erstmal vielen Dank für eure Hilfe.
Da gerade am zweiten Standort keiner zu Hause ist, kann ich leider nichts testen. Ich habe mal den Server hier vorerst auf Tunnel umgestellt. Allerdings muss ich mal die Verbindung von außen testen, um zu sehen, ob alles so funktioniert, wie es soll. Damit auch die anderen User im Forum etwas hiervon haben, werde ich meine veränderten Configs posten, sobald ich das hier zum Laufen bringe.

Danke nochmals und ich melde mich wieder, falls ich noch immer Probleme habe. Ihr habt mir aber ein riesen Stück weitergeholfen und ich werde beide Varianten testen, um das auch mal praktisch zu verstehen.

Auf bald!

 

[AlGates]

Hi!

Nachdem ich heute lange und viel herumprobiert habe, melde ich mich mal wieder zurück.
Zunächsteinmal hatte ich das OpenVPN mit Tunnel ausprobiert und hatte dabei zwar die Möglichkeit meine zweite Fritzbox aus dem Servernetz zu pingen, aber leider nicht über die dortige IP-Adresse, sondern nur über die VPN-Adresse.
Die Config sah dabei im Server so aus:

dev tun
dev-node /var/tmp/tun
mode server
tls-server
proto tcp-server
port 1194
tun-mtu 1500
ca /var/tmp/ca.crt
cert /var/tmp/fritzbox.crt
key /var/tmp/secret.key
dh /var/tmp/dh2048.pem
auth SHA1
cipher AES-256-CBC
server 192.168.200.0 255.255.255.0
client-to-client
ifconfig-pool-persist ipp.txt
float
keepalive 10 60
verb 4
mssfix
push "route 192.168.0.0 255.255.0.0"
daemon

Damit konnte ich den Client zwar pingen, aber wie gesagt eben nur mit 192.168.200.x

Dann habe ich das ganze mal mit TAP versucht und die Config sah folgendermaßen aus:

dev tap
dev-node /var/tmp/tun
mode server
tls-server
proto tcp-server
port 1194
tun-mtu 1500
ca /var/tmp/ca.crt
cert /var/tmp/fritzbox.crt
key /var/tmp/secret.key
dh /var/tmp/dh2048.pem
auth SHA1
cipher AES-256-CBC
client-to-client
ifconfig 192.168.200.1 255.255.255.0
ifconfig-pool 192.168.200.2 192.168.200.6
float
keepalive 10 60
verb 4
mssfix
comp-lzo
push "route-gateway 192.168.200.1"
push "route 192.168.188.0 255.255.255.0"
route 192.168.189.0 255.255.255.0 192.168.200.3
route 192.168.0.0 255.255.255.0 192.168.200.4
daemon

Ich hatte es zwischenzeitlich auch mit UDP versucht, aber damit gab es offenbar Probleme in der FritzBox, obwohl ich den Port 1194 in der ar7.cfg für UDP freigeschalten hatte.
Mit dieser Einstellung habe ich aber wieder das Problem, dass ich die Client-FritzBox noch nicht einmal pingen kann. Sie ist zwar verbunden, aber sie lässt sich nicht pingen und sie kann den Server selbst auch nicht pingen. Nur wenn ich einen Ping auf 192.168.200.255 mache, erreicht sie den Server.

Die Config im Client sieht so aus:

dev tap
proto tcp-client
tls-client
ns-cert-type server
ca ...
cert ...
key ...
auth SHA1
cipher AES-256-CBC
port 1194
nobind
ifconfig 192.168.200.3 255.255.255.0
comp-lzo
ping 15
ping-restart 120
resolv-retry infinite
tun-mtu 1500
mssfix
persist-tun
persist-key
verb 4
pull

Im Übrigen kommt bei dieser Einstellung ein Warning, weil angeblich "pull" und "ifconfig" nicht gleichzeitig verwendet werden sollte.

Ich hab keine Ahnung, wo das Problem liegen kann. Die Client-Box ist der absolute Stressfaktor und ich bekomme es einfach nicht hin, die irgendwie auf ihrer regulären IP-Adresse zu pingen, obwohl die Routen gesetzt sind und die Verbindungen bestehen. Aus irgendeinem Grund gehen die Pings aber nicht richtig durch.

Vielleicht hat jemand eine Idee.
Danke
Alex

 

[MaxMuster]

Hi,

da isser ja wieder ;-)

Damit konnte ich den Client zwar pingen, aber wie gesagt eben nur mit 192.168.200.x

Das wäre für mich klar, denn da fehlt die Route zu deinem "Client Netz", also was in der Art

route 192.168.189.0 255.255.255.0

Ansonsten kennt der Server zwar die IP des Clients, weiss aber nicht, was "dahinter" liegt...

Auch komme ich nochmal auf das ipp.txt-Thema zurück, was wir schonmal hatten ;-). Ich habe dazu nochmal ein wenig gesucht, und demnach ist es so, dass in der Art, wie du es jetzt hast, openvpn selbst die Datei beschreibt, um bei einem reconnect die gleiche IP zu vergeben, wenn eine 0 dahinter steht, dann machst du das "von Hand":

Aus der man-Page:
--ifconfig-pool-persist file [seconds]
Persist/unpersist ifconfig-pool data to file, at seconds intervals (default=600), as well as on program
startup and shutdown.

The goal of this option is to provide a long-term association between clients (denoted by their common
name) and the virtual IP address assigned to them from the ifconfig-pool. Maintaining a long-term as-
sociation is good for clients because it allows them to effectively use the --persist-tun option.

file is a comma-delimited ASCII file, formatted as <Common-Name>,<IP-address>.

If seconds = 0, file will be treated as read-only. This is useful if you would like to treat file as a
configuration file.

Note that the entries in this file are treated by OpenVPN as suggestions only, based on past associa-
tions between a common name and IP address. They do not guarantee that the given common name will al-
ways receive the given IP address. If you want guaranteed assignment, use --ifconfig-push

Im Übrigen kommt bei dieser Einstellung ein Warning, weil angeblich "pull" und "ifconfig" nicht gleichzeitig verwendet werden sollte.

Das ist vermutlich dein "zweites Problem": Der Server ist dafür "zuständig", dem Client eine IP zu geben, und du machst das fest. Vermutlich hat der Server dan z.B. die .2 vergeben, du hast mit dem ifconfig aber die .3 eingetragen, dann "kennt" der Server deinen Client auf IP-Basis nicht...

Jörg