OpenVPN-Paket

Gestohlen und bei ebay verkauft (natürlich ohne System CD) - und schon ist die Kiste im Internet;
Eine weitere Variante, die aber einen eigenen Webserver voraussetzt, ist es, bei jedem Starten eine Seite auf dem eigenen Server ausfuzrufen. Das kann sogar eine nicht existierende Seite sein - gibt dann Einträge im error_log, die sich leicht heraus-grepen lassen.
 
NAT über OpenVPN Tunnel

Folgendes Problem:

Der Tunnel baut wunderbar auf, funktioniert auch einwandfrei. Nun will ich in das besagte Netz NATen mit der fritzbox um nach aussen die ip vom Tunnel zu haben.

Ist es möglich dies ohne IPtables+NAT zu realisieren oder muss ich dazu wirklich mein image neu bauen? :)

BOX: FritzBox Fon WLAN 7170 mit der .37 FW und dsmod 15.2
 
OpneVPN selbst hat meines Wissens keine eigene NAT Funktionalität, die OpenVPN Seiten, die ich hier auch gerne nochmal nenne, verweisen dafür auch auf iptables.

Jörg
 
Das ist mir schon klar. Die frage ist, kann man das vorhandene NAT der fritz.box manipulieren, z.b. mit der ar7.cfg oder so. Weil NAT ansich muss sie ja können, sonst würde das ja beim "normalen" internet auch nicht gehen.
 
Nee, das sind zwei grundsätzlich verschiedene Ebenen:
Die NAT für die Internetverbindung ist (für manche leider) unabschaltbar im dsld vorhanden.
Die VPN-Verbindung ist aber im "normalen Routing" und von daher nicht damit in Verbindung zu bringen (ist zumindest mein Kenntnisstand).

Jörg
 
Bimbes schrieb:
...
Der Tunnel baut wunderbar auf, funktioniert auch einwandfrei. Nun will ich in das besagte Netz NATen mit der fritzbox um nach aussen die ip vom Tunnel zu haben.
...
Kannst Du mal kurz erläutern, aus welchem Grund Du das so haben möchtest.
Aus meiner Sicht macht das nämlich relativ wenig Sinn; ich sehe das Netz des Tunnels als reines Transportnetz. OpenVPN spielt dabei die Rolle eines Routers und zwar auf zwei Ebenen. Einmal das Routing zu der Maschine, auf der die OpenVPN Anwendung läuft und optional auf die Netze hinter den OpenVPN-Endpunkten.
Aber vielleicht hast Du was bestimmtes vor und meine Interpretation ist lückenhaft.
 
Ich gebe mal eine (ungefragte) Antwort: Wenn du keinen Zugriff auf den Server hast (also dort kein Routing auf dein Clientnetz eintragen kannst/willst/darfst) ist es natürlich "elegant", wenn du das Netz beim Client hinter der VPN-Tunnel_IP des Clients "verstecken" kannst, wenn diese IP im Umfeld des Servers geroutet wird.

Jörg
 
maceis schrieb:
ich sehe das Netz des Tunnels als reines Transportnetz.
Das sehe ich genauso. Ein Tunnel ist bei mir stets ein eigener Netzwerkbereich. So kann man alles viel besser auseinander halten.
 
Der sinn dahinter ist ganz klar, die Netzstruktur vor dem Router zu verbergen...

Vllt als erläuterung der aufbaue des netz:

192.168.1.1/24 -> 192.168.1.1 ROUTER 10.8.0.10 -> VPN <- 10.8.0.9 VPN SERVER NAT öffentliche IP -> INTERNET

Das NAT auf dem VPN server ist jedoch lediglich für die 10.8.0.10 eingestellt und nicht für das Netz vor dem Router 192.168.1.1/24

Am System und an der Struktur kann sich nichts ändern, sprich ich muss im Prinzip das NAT auf dem Router machen um mit meinen Rechner vor den Router die öffentliche IP zu nutzen. Mir ist klar das man da auch noch anders regeln kann, aber wenn man keinen Zugriff auf den VPN server hat, dann wird das wohl nicht möglich sein :)


Die Sache ist halt ob ich das eingebaute NAT vom Router nehmen kann oder ob ich wirklich iptables+NAT einbauen muss. Weil mit iptables hatte ich Stabilitätsprobleme in der Vergangenheit (Regelmäßige Neustarts)
 
Ich kann Dir immer noch nicht ganz folgen.
Die Netzstruktur vor dem Router zu verbergen ist sinnlos, denn dann kann der Router nicht mehr routen.
Außerdem müsste es genügen, wenn das NAT auf dem OpenVPN Server auf das OpenVPN Netz eingestellt ist, da man das NAT i.d.R. nur da machen muss (und es nur da Sinn hat), wo eine Umsetzung von privaten auf öffentliche Adressen (oder umgekehrt) erfolgt. Die öffentliche IP vor dem Router nutz Dir nichts, da Du dann nicht durch das OpenVPN kommst. Es ist außerdem so, dass in dem von Dir beschriebenen Netzwerkaufbau nur der VPN SERVER (und dahinter liegende Geräte) entscheiden kann (können), was in Richtung Internet geroutet wird .

Irgendwo scheint mir da ein Knoten in Deinem (oder vielleicht auch in meinem) Gedankengang zu sein.
 
Zuletzt bearbeitet:
maceis schrieb:
Die Netzstruktur vor dem Router zu verbergen ist sinnlos, denn dann kann der Router nicht mehr routen [....] Irgendwo scheint mir da ein Knoten in Deinem (oder vielleicht auch in meinem) Gedankengang zu sein.
Das macht schon Sinn, es ist halt so ähnlich wie bei deinem Internetzugang. Dort "versteckst" du dein LAN zum Internet hin hinter der IP des Routers, weil nur diese IP im Internet "bekannt" und routbar ist (und damit ist das Internet erst nutzbar). Analog kann es nötig sein, dass du das Netz gegenüber den Netzen beim VPN-Server "versteckst" wenn die VPN-Client-IP dort geroutet wird.
Das ist dann nötig, wenn du auf das Netz, auf das du zugreifen willst, keinen Einfluss hast, deine "Gatewayadresse" aber in diesem Netz bekannt ist. Das gilt sicher fürs Internet, kann aber halt auch mal für andere Netze gelten...

Jörg
 
MaxMuster schrieb:
Das macht schon Sinn, es ist halt so ähnlich wie bei deinem Internetzugang. Dort "versteckst" du dein LAN zum Internet hin hinter der IP des Routers, weil nur diese IP im Internet "bekannt" und routbar ist (und damit ist das Internet erst nutzbar). Analog kann es nötig sein, dass du das Netz gegenüber den Netzen beim VPN-Server "versteckst" wenn die VPN-Client-IP dort geroutet wird.
Das ist dann nötig, wenn du auf das Netz, auf das du zugreifen willst, keinen Einfluss hast, deine "Gatewayadresse" aber in diesem Netz bekannt ist. Das gilt sicher fürs Internet, kann aber halt auch mal für andere Netze gelten...

Jörg

Genau! Im Prinzip ist es wirklich wie beim NATen im Internet zu verstehen. Der VPN Server kann halt mit meinem privaten Netz nix anfangen sondern nur mit dem 10er Netz vom Tunnel. Und da ich keinerlei Einfluss auf den Server hab, kann ich da auch nichts dran ändern. Sprich im Prinzip wird das ganze zweimal genattet. Einmal solls von der Fritzbox vom 192er Netz ins 10er und dann vom VPN Server vom 10er in die öffentliche IP
 
Ach so meinst Du das.
Mit "Netz vor dem Router verstecken" meinst Du, "das Netz, das vor dem Router ist" und nicht "vor dem Router verstecken".
Jetzt habe ich verstanden, was Du meinst.
Im Grunde ist es eine Masquerading zwischen dem 192.168.1-er Netz und dem 10-er Netz.
Ich weiß zwar nicht, was für einen Sinn es macht, dass der VPN SERVER anscheinend nur 10-er Adressen ins Internet lässt, aber das ist für Dein problem eigentlich auch unerheblich.
 
Also bei mir gibt es mit dem Package von MaxMuster nach wie vor Probleme im Betriebsmodus "Server mit Zertifikaten". Ich verwende einen aktuellen SVN Checkout, wo das Package bereits von Olistudent eingepflegt wurde (ich hatte es bisher noch nicht eingecheckt, weil es bei mir Probleme macht):

Code:
 $ /etc/init.d/rc.openvpn start
Starting openvpn ... Trace/breakpoint trap
failed.

Code:
$ strace openvpn --config /mod/etc/openvpn.conf
...
open("[b]/tmp/flash/dh.pem[/b]", O_RDONLY)     = 4
ioctl(4, TIOCNXCL, 0x7f898d90)          = -1 ENOTTY ([b]Inappropriate ioctl for device[/b])
brk(0x487000)                           = 0x487000
$ ls -la /tmp/flash/dh.pem 
-rw-r--r--    1 root     root          245 Oct  6 18:17 /tmp/flash/dh.pem

Code:
$ cat /mod/etc/conf/openvpn.cfg
export OPENVPN_ADDITIONAL='#'
export OPENVPN_AUTH_TYPE='static#certs'
export OPENVPN_AUTOSTART='#'
export OPENVPN_BOX_IP='#192.168.200.1'
export OPENVPN_BOX_MASK='255.255.255.0#255.255.255.0'
export OPENVPN_CIPHER='BF-CBC#BF-CBC'
export OPENVPN_CLIENT2CLIENT='#'
export OPENVPN_CLIENTS_DEFINED='#0'
export OPENVPN_CLIENT_INFO='#'
export OPENVPN_CLIENT_IPS='#'
export OPENVPN_CLIENT_MASKS='#'
export OPENVPN_CLIENT_NAMES='#'
export OPENVPN_CLIENT_NETS='#'
export OPENVPN_COMPLZO='yes#yes'
export OPENVPN_CONFIG_COUNT='1'
export OPENVPN_CONFIG_NAMES='DEFAULT#'
export OPENVPN_DEBUG='#'
export OPENVPN_DEBUG_TIME='10#10'
export OPENVPN_DHCP_CLIENT='#'
export OPENVPN_DHCP_RANGE='#192.168.200.2 192.168.200.254'
export OPENVPN_ENABLED=''
export OPENVPN_EXPERT='yes'
export OPENVPN_FLOAT='#'
export OPENVPN_KEEPALIVE='yes#yes'                      
export OPENVPN_KEEPALIVE_PING='10#10'
export OPENVPN_KEEPALIVE_TIMEOUT='120#120'
export OPENVPN_LOCAL='#'
export OPENVPN_LOCAL_NET='#'
export OPENVPN_LOGFILE='#'
export OPENVPN_MAXCLIENTS='1#3'
export OPENVPN_MGMNT='#'
export OPENVPN_MODE='server#server'
export OPENVPN_MTU='1500#1492'
export OPENVPN_OWN_KEYS='#'
export OPENVPN_PORT='#1194'
export OPENVPN_PROTO='udp#udp'
export OPENVPN_PULL='#'
export OPENVPN_PUSH_DNS='#'
export OPENVPN_PUSH_WINS='#'
export OPENVPN_REDIRECT='#'
export OPENVPN_REMOTE='#'
export OPENVPN_REMOTE_IP='#192.168.200.2'
export OPENVPN_REMOTE_NET='#'
export OPENVPN_SHAPER='#'
export OPENVPN_TLS_AUTH='#yes'
export OPENVPN_TYPE='tun#tap'
export OPENVPN_UDP_FRAGMENT='#'
export OPENVPN_VERBOSE='3#3'

Wäre interessant zu wissen, ob es bei anderen funktioniert, als "Server mit Zertifikaten"?
 
Ich werde mal versuchen, diese config bei mir zu nutzen.
Vorher aber noch: Der Fehler tritt beim Starten des openvpn auf? Daran habe ich aber "nix gemacht", sondern nur die GUI und die Skripte rundum zum Bauen der Konfig usw. angepasst. Das Binary wurde so gebaut "wie immer", mit den Änderungen zur "Namensgebung" mit/ohne LZO.

Jörg
EDIT
Bei mir geht es mit der Konfig (erzeugt mit einem "kompletten Firmwareneubau" aus dem SVN vom 20.10.):
Code:
~ $ /etc/init.d/rc.openvpn start
Starting openvpn ... done.
~ $ cat /mod/etc/conf/openvpn.cfg
export OPENVPN_ADDITIONAL='#'
export OPENVPN_AUTH_TYPE='static#certs'
export OPENVPN_AUTOSTART='#'
export OPENVPN_BOX_IP='#192.168.200.1'
export OPENVPN_BOX_MASK='255.255.255.0#255.255.255.0'
export OPENVPN_CIPHER='BF-CBC#BF-CBC'
export OPENVPN_CLIENT2CLIENT='#'
export OPENVPN_CLIENTS_DEFINED='#0'
export OPENVPN_CLIENT_INFO='#'
export OPENVPN_CLIENT_IPS='#'
export OPENVPN_CLIENT_MASKS='#'
export OPENVPN_CLIENT_NAMES='#'
export OPENVPN_CLIENT_NETS='#'
export OPENVPN_COMPLZO='yes#yes'
export OPENVPN_CONFIG_COUNT='1'
export OPENVPN_CONFIG_NAMES='DEFAULT#'
export OPENVPN_DEBUG='#'
export OPENVPN_DEBUG_TIME='10#10'
export OPENVPN_DHCP_CLIENT='#'
export OPENVPN_DHCP_RANGE='#192.168.200.2 192.168.200.254'
export OPENVPN_ENABLED=''
export OPENVPN_EXPERT='yes'
export OPENVPN_FLOAT='#'
export OPENVPN_KEEPALIVE='yes#yes'
export OPENVPN_KEEPALIVE_PING='10#10'
export OPENVPN_KEEPALIVE_TIMEOUT='120#120'
export OPENVPN_LOCAL='#'
export OPENVPN_LOCAL_NET='#'
export OPENVPN_LOGFILE='#'
export OPENVPN_MAXCLIENTS='1#3'
export OPENVPN_MGMNT='#'
export OPENVPN_MODE='server#server'
export OPENVPN_MTU='1500#1492'
export OPENVPN_OWN_KEYS='#'
export OPENVPN_PORT='#1194'
export OPENVPN_PROTO='udp#udp'
export OPENVPN_PULL='#'
export OPENVPN_PUSH_DNS='#'
export OPENVPN_PUSH_WINS='#'
export OPENVPN_REDIRECT='#'
export OPENVPN_REMOTE='#'
export OPENVPN_REMOTE_IP='#192.168.200.2'
export OPENVPN_REMOTE_NET='#'
export OPENVPN_SHAPER='#'
export OPENVPN_TLS_AUTH='#yes'
export OPENVPN_TYPE='tun#tap'
export OPENVPN_UDP_FRAGMENT='#'
export OPENVPN_VERBOSE='3#3'
~ $ cat /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Sat Oct 27 09:36:00 CEST 2007
proto udp
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
mode server
ifconfig-pool 192.168.200.2 192.168.200.254
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
max-clients 3
tun-mtu 1492
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120
~ $ ps | grep openvpn
  418 root       2768 S   openvpn --config /mod/etc/openvpn.conf --writepid /var/run/openvpn.pid
  422 root       1408 S   grep openvpn
~ $

EDIT2 Ich hatte bei meinen Äderungen auch die Datei "dh_pem.def" leicht verändert (damit sie für das Erstellen der "eigenen Keys" in openvpn_dynamic_conf besser geeignet war). Könnte es sein, wenn das an der Stelle bei dir abbricht, dass da ein "Versionsproblem" existiert, weil bei dir noch die ältere Version vorliegt?
 
Zuletzt bearbeitet:
Zusätzliche Einstellungen in openvpn-lzo.conf

Ich möchte zusätzliche Optionen in die openvpn-lzo.conf dauerhaft eintragen, wie mache ich das, ohne das sie beim nächsten openvpn Start wieder überschrieben werden?? Hintergrund, ich wähle mich mit meinem Notebook per analogem Modem in meinen VPN-Server ein, der Tunnel wird auch in Richtung Notebook aufgebaut, aber kein Ping in Richtung Tunnel IP - Server und kein Ping vom VPN-Server Richtung VPN-Client IP (das Notebook) möglich. Ich vermute ein Routingproblem, komme aber seit 2 Wochen nicht weiter. Oder hat von euch jemand eine Idee wie es geht??
 
Was für einen Parameter willst du denn Eintragen? Zunächst kannst du den natürlich testen, indem du die /mod/etc/openvpn-lzo.conf nach /var/tmp kopierst, die dort veränderst und dann (nachdem der "normale" Dienst gestoppt wurde) mit
Code:
openvpn --config /var/tmp/openvpn-lzo.conf
startest.

Permanent was eintragen kannst du z.B. mittels eines veränderten Configurationsskriptes (statt "/etc/default.openvpn/openvpn-lzo_conf" in "/var/tmp/flash/openvpn-lzo_conf" [ob da die "lzo"s mit drin steht weiß ich nicht] ). Du kannst auch die "neue GUI" von mir nutzen, da gibt es die Möglichkeit, zusätzliche Dinge einzutragen, das erfordert aber etwas "Handarbeit"...

Jörg
 
Ich will mit den zusätzlichen Optionen experimentieren, weil im Augenblick kein Byte über meinen Tunnel geht (in beiden Richtungen) Ich hatte in der Server-conf zunächst an "push redirect-gateway" gedacht.
 
@ Max Muster
könntest Du mir mal Schritt für Schritt erklären, wie ich die neue GUI von dir in den ds-mod einbaue!?
 
Ich kann es ja mal versuchen, aber es ist meiner Ansicht nach das verkehrte Vorgehen für dein Problem...
Nimm den Anhang, packe den innerhalb deines ds26-15.2 Verzeichnisses aus und baue den mod neu. Das sollte es gewesen sein (ohne Garantie ;-))

Aber ich denke eher, du solltest dich dem Problem auf dem "herkömmlichen" Wege nähern, den ich oben beschrieben habe. Kopiere die Config Datei nach /var/tmp, nimm dann die Option "daemon" raus und setze "verb 6", da wirst du ziemlich sicher herausfinden, wo es hängt...

Jörg
 

Anhänge

  • ovpn_tmp.tgz
    190 KB · Aufrufe: 4
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.