Routing Denkfehler ? wo liegt der Wurm?

Also, beide Linksys-WRT54GL stehen hinter den Internetroutern. Ich vesuch das zu veranschaulichen:


Site(A) 10.20.30.0/24---------------------------------------------------------------------------------------Site(B)192.168.0.0/24

WRT54GL 10.20.30.2 >> Internetrouter 10.20.30.1 <<==>> Internetrouter 192.168.0.1 << WRT54GL 192.168.0.2


Auf dem Internetrouter 10.20.30.1 habe ich zwei statische Routen eingetragen, und zwar:
192.168.0.0/24 via 10.20.30.2 und ebenso auch 10.10.10.0/24 via 10.20.30.2

Auf dem Internetrouter 192.168.0.1 habe ich zwei statische Routen eingetragen, und zwar:
10.20.30.0/24 via 192.168.0.2 und ebenso auch 10.10.10.0/24 via 192.168.0.2

Der Endpunkt auf Site(A) auf dem WRT54GL OpenVPN Router (client) hat die 10.10.10.6
Der Endpunkt auf Site(B) auf dem WRT54GL OpenVPN Router (server) hat die 10.10.10.1

OpenVPN wird im Multi-Client-Betrieb betrieben, hier die server-config auf site(B) 192.168.0.2:

Und hier die OpenVPN-Config des OpenVPN-Clients aus siteA 10.20.30.2:

Routing-Table des OpenVPN-Routers 10.20.30.2 auf SiteA:

Routing-Table des OpenVPN-Routers 192.168.0.2 auf SiteB:

Auf beiden OpenVPN-Routern (Linksys WRT54GL) habe ich "/etc/init.d/firewall stop" abgesetzt und mit "iptables -L" vergewissert, dass keine FW aktiv ist. Auf SiteB habe ich sämtlich Firewalls und IntrusionDetection Systeme ausgeschaltet, auf SiteA gibts das nicht, weil dort die FritzBox als Internetrouter eingesetzt wird. Ich kann leider das Paket tcpdump mit "opkg install tcpdump" auf den OpenVPN-Routern nicht finden und installieren, gibts wohl nicht? Dort läuft die aktuellste OpenWRT Version.

Ping-Tests vom OpenVPN-Router 10.20.30.2 auf SiteA:
- ich kann den OpenVPN-server Endpunkt anpingen, Ping auf 10.10.10.1 POSITIV
- ich kann sämtliche Hosts aus dem Netz SiteB anpingen, Ping auf 192.168.0.* POSITIV

Ping-Tests vom OpenVPN-Router 192.168.0.2 auf SiteB:
- ich kann den OpenVPN-Client Endpunkt anpingen, Ping auf 10.10.10.6 POSITIV
- ich kann KEINE weiteren Hosts auf SiteA anpingen, Ping auf 10.20.30.* NEGATIV

Ich seh den Holzwurm nicht

HURRRAAA!!! Hab den Wurm gefunden. Es war ein Typo von einem einzigen Buchstaben, und zwar in dem client-config-dir das für den Multi-Server-Betrieb des OpenVPN verwendet wird. Dort hatte ich im Dateinamen einen typo-Fehler stehen in der Datei, somit konnte die Zuordnung nicht erfolgen, und entsprechend der iroute Befehl nicht gesendet werden. Maaaaannnn, das hat mich einen ganzen Tag gekostet, uaaaah

Hauptsache Problem gelöst. Dank hochschrauben des debug levels und Logfile auf server-side.

Dennoch danke für eure Hilfestellungen, thanks to all!!!

@aqui: doch, orcape hat Recht. iroute MUSS sein! Das Thema hatten wir doch schonmal, wenn du/ihr euch erinnert:
Fragen zu OpenVPN unter OpenWRT
Das ist dieses Multi-Server-Modell in OpenVPN.

@orcape: Ja genau richtig! Gut aufgepasst ;) ich hatte mir auch schon den Wolf abgesucht, hehe. Und alles wegen nur einem Buchstabendreher innerhalb meines client-config-dirs, argh!

Letztendlich hat's aber doch noch geklappt *freu*

Hi aqui,

nein, es ist nur ein einzelner OpenVPN-Server. Aber du kannst diesen im Multiclient-Betrieb (als Roadwarrior) betreiben. Das heisst es läuft ein interner DHCP-Server auf dem OpenVPN-Server, und es können sich gleichzeitig mehrere VPN-Clients andocken. Jeder VPN-Client bekommt dabei seinen eigenen Adressbereich vom Server zugeteilt, und die Abwicklung erfolgt dabei durch iroute, das ist zwingend notwendig. Nähere Infos hatte ich damals bereits in meinem anderen Beitrag gepostet (siehe Fragen zu OpenVPN unter OpenWRT)

Ich zitiere mich selbst:


http://openvpn.net/index.php/open-source/documentation/howto.html

http://openvpn.net/index.php/open-source/documentation/manuals/65-openv ...

Suchbegriff "--server network netmask"

Viele Grüße,
Pangu

Nochmal: es ist kein standard-Verhalten bei OpenVPN. Der Multiclient-Betrieb wird durch folgende Direktive initiiert. Natürlich können durch OpenVPN mehrere Clients abgewickelt werden, aber durch diesen Modus erfolgt das auf eine ganz andere Art, und zwar indem Teilnetze (kleine Subnetze von OpenVPN und dessen initiierten DHCP-Server dafür initiiert werden!) Dieses Modell gibts erst ab OpenVPN Version 2.x
Was du beschreibst ist das klassische Modell, aber ich rede hier von einem anderen, und zwar nennt sich das eben nunmal Multi-Client Modell und du kannst es in jeder OpenVPN Doku nachlesen. Zur Hilfe: Aus meinem letzten Beitrag, der letzte Link, dort nach --server network netmask suchen, ergibt das hier:

Server Mode
Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode is supported, and can be enabled with the --mode server option. In server mode, OpenVPN will listen on a single port for incoming client connections. All client connections will be routed through a single tun or tap interface. This mode is designed for scalability and should be able to support hundreds or even thousands of clients on sufficiently fast hardware. SSL/TLS authentication must be used in this mode.

--server network netmask
A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.

For example, --server 10.8.0.0 255.255.255.0 expands as follows:


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"

Und weswegen iroute steht hier beschrieben --> http://backreference.org/2009/11/15/openvpn-and-iroute/

Aber die ganze Diskussion hatten wir doch schonmal, ich erinnere nochmal --> Fragen zu OpenVPN unter OpenWRT

Grüße,
Pangu.

der ledigliche "route"-Befehl wickelt den Verkehr zwischen Kernel und VPN-Server ab, wogegen "iroute" den Verkehr zwischen dem Server und den jeweiligen Clients leitet.

Steht doch alles in der offiziellen OpenVPN-HowTo aufrufen unter den Link --> http://openvpn.net/index.php/open-source/documentation/howto.html

und dort nach Including multiple machines on the client side when using a routed VPN (dev tun) suchen

Da werden alle Fragen beantwortet.

Gruß,
Pangu

Aqui, glaubst du wirklich, OpenVPN baut eine Funktion ein, die man hätte gar nicht benötigt? du hast es wohl entweder noch nicht durchgelesen, oder nicht verstanden. Ich erspar mir daher, noch irgendwas zu verlinken wo das deutlich beschrieben wird.

Lieber aqui, das eine hat mit dem anderen nichts zu tun. Du stellst hier in den Raum, dass iroute und dass das Multiclient-modell von OpenVPN totaler Schwachsinn und kein Mensch benötige. Und das nur, weil du es nicht benötigst, nicht begreifst, oder nicht begreifen möchtest. Das ist so, als ob du behauptest kein Mensch braucht eine Gabel in der Küche, weil man eh töglich Suppe ißt. Das ist doch absurd und absolut lächerlich. Es geht hier nicht darum was DU brauchst oder für angemessen hältst, sondern darum dass es eben ein Multiclient-Modell von OpenVPN gibt, dieses ausagekräftig seitens Hersteller ausreichend dokumentiert ist, und dass auch weltweit wie beschrieben unter bestimmten Voraussetzungen eingesetzt wird. Wenn du es nicht brauchst, schön, dann lass es einfach. Aber werfe bitte nicht in den Raum, dass es Schwachsinn wäre und total irrelevant ist, denn du hast wirklich nicht verstanden wozu es das gibt. Du kannst aber gerne den developern von OpenVPN eine Nachricht mit deiner Meinung zukommen lassen, viel Erfolg!

Anhand meines Postings ganz am Anfang erkläre und verdeutliche ich deutlich, dass ich mit verschiedenen Clients aus dem Heim-Netz aus, Hosts ins entfernte Netz erreichen möchte. Dazu habe ich auch genau den Aufbau der Router beschrieben und alle hierzu notwendigen Details geliefert. Hier wird sofort klar, dass ich nicht von einem Dial-In-Blabla-Szenario rede wie du hier ständig immer wiederholst. Ich möchte ALLEN meinen Clients aus dem Heimnetz erlauben, Hosts aus dem Remotenetzwerk zu erreichen. Und da wirklich einfach nur stur oder zu faul zum Lesen bist, poste ich hier nochmal aus der Original OPENVPN-HOWTO die Erklärung hierzu:

Including multiple machines on the client side when using a routed VPN (dev tun)

In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate ("client2" in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"

This will cause the OpenVPN server to advertise client2's subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.


Am besten du scrollst nochmal hoch, liest dir mein Ursprungspost durch und merkst hoffentlich, was du hier zu diesem Thema gepostet hast. Nix für ungut, bei allem Respekt liber aqui. Ich kenne deine OpenVPN-HowTo, aber lies dir bitte genau das Problem durch, und poste nicht immer gleich einfach dein Link zur HowTo. Du wimmelst hier die Antworten der anderen helfenden User ab, nur weil du es a.) nicht verstehen willst, oder b.) dich stur stellst und es verbal so hindrehst, dass es eh kein Mensch braucht. Meine Frage bezieht sich auf die Thematik XYZ und weils dir nicht reinpasst gibst du deinen Senf dazu ab. Was soll man(n) denn dazu denken? Das ist wirklich lächerlich, ganz ehrlich! In diesem Sinne hab ich dir wirklich nicht meht dazu sagen, ich hab dir jetzt schon zig mal die ofiziellen Erklärungen zu diesem Thema seitens OpenVPN gepostet. Mach was du für richtig hältst, nur weiter so...

Und nochmals, danke an den Rest. Schönen Abend an Alle

@108012:

- die statische Route WAR gesetzt ! Das steht auch in meinem Ursprungspost drin! wer lesen kann ist klar im Vorteil

- ich versuche so genau wie möglich mein Problem zu beschreiben und zu illustrieren. Nachdem das angeblich eurer Meinung nicht der Fall war, habe ich es nochmals verdeutlicht. Einfach mal hochscrollen und dir meine Postings mit all den Configs und Details durchlesen. Du kannst mir das also nicht unterstellen. Vielmehr merke ich, dass du hier auch vom Thema abschweifst und persönlich wirst. Das eine hat aber mit dem anderen nichts zu tun.

- den Link mit dem iRoute, den du hier postest kenne ich, denn ich hab ihn bereits in meinem letzten Beitrag zu dieser Angelegenheit (siehe --> Fragen zu OpenVPN unter OpenWRT) durch Recherche entdeckt gehabt und auch damals gleich gepostet. Dass du mir jetzt diesen gleichen Link nochmal präsentiert, wow ich bin gerührt.

- ich mach hier keinen an weil er mir helfen möchte, im Gegenteil: ich bedanke mich für die Hilfe. Aber du scheinst wohl ein ganz anderes Problem mit mir oder allgemeiner Natur zu haben und machst mich grad dumm an. Deine Art, wie du auf Beiträge antwortest habe ich bereits des Öfteren bemerkt und hast es auch in dem letzten Beitrag zu der OpenVPN/iRoute Geschichte wieder bewiesen (siehe Fragen zu OpenVPN unter OpenWRT).

Und um nicht weiter auszuschweifen und nach 10 Jahren hier in den Artikel schauende User noch mehr mit BlaBla abzulenken, lege ich dir oder sonstwem nochmal ans Herz dich mit iroute auseinanderzusetzen und wofür es gedacht ist. Dann wird du oder aqui HOFFENTLICH endlich mal verstehen, dass route und iroute zwei verschiedene Sachen sind, und dass es darauf ankommt ob ein Client nur einen einzelnen Host im entfernten Host ansprechen will, oder die Dienste für das gesamte Subnet anbieten möchte. Und deswegen und nur deswegen gibts auch in OpenVPN die Möglichkeit diese Bedürfnisse über iroute zu regeln. Und weils anscheinend auch bei dir nicht rübergekommen ist, hier nochmals:

Warum iroute ? Original Beschreibung aus der ofiziellen OpenVPN HowTo command reference!

--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.

This directive can be used to route a fixed subnet from the
server to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to
the system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.

This option must be specified either in a client instance config
file using --client-config-dir or dynamically generated using a
--client-connect script.

The --iroute directive also has an important interaction with
--push "route ...". --iroute essentially defines a subnet which
is owned by a particular client (we will call this client A).
If you would like other clients to be able to reach A's subnet,
you can use --push "route ..." together with --client-to-client
to effect this. In order for all clients to see A's subnet,
OpenVPN must push this route to all clients EXCEPT for A, since
the subnet is already owned by A. OpenVPN accomplishes this by
not not pushing a route to a client if it matches one of the
client's iroutes.

iroute und route sind zwei verschiedene Sachen, und es geht wie in meinem Ursprungspost deutlich beschrieben darum, mehrere Clients hinterm OpenVPN-Punkt zu versorgen. Und wenn du jetzt ebenso wie aqui beharrst, dass kein Mensch iroute braucht, dann viel Spass und viel Erfolg. Dann habt ihr wirklich noch mehr Durchblick in OpenVPN wie die Entwickler selbst und dessen Dokumentationen.