OpenVPN-Paket
- Ersteller lord-of-linux
- Erstellt am
...danke stinkstiefel.
avm-firewall gehört nicht zufällig auch noch dazu? dann muß man die ar7.cfg nicht editieren, oder?
Zur Konfiguration kannst Du nichts beitragen?
Gruß
Wolfgang
avm-firewall gehört nicht zufällig auch noch dazu? dann muß man die ar7.cfg nicht editieren, oder?
Zur Konfiguration kannst Du nichts beitragen?
Gruß
Wolfgang
War denn beim Lesen dieser Thread auch dabei, oder dieser? Bei beiden ging es um SwissVPN und die Verbindung hat geklappt, beim zweiten sogar inclusive iptables. Arbeite die doch mal durch, damit solltest du das auch hinbekommen ;-).
Jörg
Danke Jörg für den Hinweis. Ich werde das jetzt nochmals probieren.
Den ersten von Dir genannten Thread hab ich übersehen.
Wenn es denn nicht hinhaut, dann würde ich Dir nochmals "nochmals auf die Pelle rücken".
Wolfgang
Den ersten von Dir genannten Thread hab ich übersehen.
Wenn es denn nicht hinhaut, dann würde ich Dir nochmals "nochmals auf die Pelle rücken".
Wolfgang
cando
Aktives Mitglied
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Ich weiss, es ist ein sehr alter Thread, aber ich habe mich mit dem Thema openvpn noch nie wirklich auseinandergesetzt.
Muss man die Bibliotheken statisch bauen, damit es mit dem AVM SSL keine Probleme gibt, oder kann man die auch dynamisch bauen? Ich habe die 7390 Fon WLAN mit DECT und wollte mal das openvpn antesten. Welche Optionen im Menuconfig von openvpn braucht man dafür? (statische Bibliotheken, lzo Kompressen, Management Console, Optimierung der Größe?)
Danke für Eure Tipps!
Muss man die Bibliotheken statisch bauen, damit es mit dem AVM SSL keine Probleme gibt, oder kann man die auch dynamisch bauen? Ich habe die 7390 Fon WLAN mit DECT und wollte mal das openvpn antesten. Welche Optionen im Menuconfig von openvpn braucht man dafür? (statische Bibliotheken, lzo Kompressen, Management Console, Optimierung der Größe?)
Danke für Eure Tipps!
Seit die Freetz-Libs in einem eigenen Verzeichnis sind, sollte auch dynamisches Bauen kein Problem mehr sein (wenn nichts anderes dis SSL-Libs benötigt, dürfte statisch Linken aber im Resultat ein noch etwas kleineres Binary ergeben, als Binary + Libs).
LZO ist für die Komprimierung der Daten, wenn die Gegenstelle das benötigt, muss es drin sein, aber ansonsten sollte es auch nicht Schaden; ich würd es immer mit reinnehmen, denn bei der Box sollte der Größenunterschied nicht so stark "schmerzen".
Ob du die Management-Konsole brauchst denke ich eher nicht (wenn du danach fragst ;-)); die Größenoptimierung nimmt ein paar weniger gebräuchliche Optionen "en block" aus dem Binary (hauptsächlich z.B. detaillierte Help-Message).
Jörg
LZO ist für die Komprimierung der Daten, wenn die Gegenstelle das benötigt, muss es drin sein, aber ansonsten sollte es auch nicht Schaden; ich würd es immer mit reinnehmen, denn bei der Box sollte der Größenunterschied nicht so stark "schmerzen".
Ob du die Management-Konsole brauchst denke ich eher nicht (wenn du danach fragst ;-)); die Größenoptimierung nimmt ein paar weniger gebräuchliche Optionen "en block" aus dem Binary (hauptsächlich z.B. detaillierte Help-Message).
Jörg
Hallo cando,
auf meiner 7170 läuft bzw. lief OpenVPN in Verbindung mit external problemlos. Soweit ich glaube zu wissen, vergrößern statische Libs das Image, deshalb hab' ich die Option immer weggelassen. Alles andere hab' ich ausgewählt. Wie gesagt, zumindest aus dem aktuellen stable-branch läuft (auf meiner 7170) alles einwandfrei.
Grüße,
JD.
auf meiner 7170 läuft bzw. lief OpenVPN in Verbindung mit external problemlos. Soweit ich glaube zu wissen, vergrößern statische Libs das Image, deshalb hab' ich die Option immer weggelassen. Alles andere hab' ich ausgewählt. Wie gesagt, zumindest aus dem aktuellen stable-branch läuft (auf meiner 7170) alles einwandfrei.
Grüße,
JD.
sbe-michael
Neuer User
- Mitglied seit
- 9 Okt 2010
- Beiträge
- 23
- Punkte für Reaktionen
- 0
- Punkte
- 1
Zwei Fritzboxen mit OpenVPN-Tunnel verbunden - Sprache Siptelefonie
Ich habe hier zwei Fritzboxen per VPN-Tunnel über das Internet mit einander verbunden. Eine der Fritzboxen ist VPN-Server, die andere VPN-Client.
Ich habe das Routing des Clients so eingestellt, dass alle Verbindungen über den VPN-Tunnel geleitet werden. Ich kann vom Client in das Netz der Serverbox pingen und auch umgekehrt vom Server in das Netzwerk der Clientbox. Alles sehr schön.
Ein Problem habe ich aber dennoch: An der Clientbox ist ein analoges Telefon angeschlossen. Die Clientbox registriert die Internetrufnummer 622 am Sip-Server der Serverbox. Auch das funktioniert wunderbar. Die Rufsignalisierung in beide Richtungen (das ist Port udp 5060) funktioniert einwandfrei. Lediglich die Sprache wird nicht übertragen. Das ist nicht schön, wenn man tatsächlich telefonieren möchte.
Wenn ich von der Clientbox ein Internetrufnummer bei 1und1 registriere habe ich dieses Problem übrigens nicht.
Im Grunde sieht das aus wie dieses Problem hier. Mir ist aber im Augenblick überhaupt nicht klar auf welcher Seite, wo und wann die Sprachpakete verworfen werden und wie ich das herausfinden könnte.
Es wäre schön, wenn mir da mal jemand helfen könnte
Ein paar Infos zu den Fritzboxen:
Fritzbox 1 - Openvpn-Server
192.168.0.0/24 -> eth0 192.168.0.1
10.8.0.0/24 -> tun0 10.8.0.1
Fritzbox 2 - Openvpn-Client
192.168.4.0/24 -> eth0 192.168.4.4
tun0 10.8.0.4
Internetrufnummer 622 am Sip-Server von FB1 192.168.0.1
Ich habe hier zwei Fritzboxen per VPN-Tunnel über das Internet mit einander verbunden. Eine der Fritzboxen ist VPN-Server, die andere VPN-Client.
Ich habe das Routing des Clients so eingestellt, dass alle Verbindungen über den VPN-Tunnel geleitet werden. Ich kann vom Client in das Netz der Serverbox pingen und auch umgekehrt vom Server in das Netzwerk der Clientbox. Alles sehr schön.
Ein Problem habe ich aber dennoch: An der Clientbox ist ein analoges Telefon angeschlossen. Die Clientbox registriert die Internetrufnummer 622 am Sip-Server der Serverbox. Auch das funktioniert wunderbar. Die Rufsignalisierung in beide Richtungen (das ist Port udp 5060) funktioniert einwandfrei. Lediglich die Sprache wird nicht übertragen. Das ist nicht schön, wenn man tatsächlich telefonieren möchte.
Wenn ich von der Clientbox ein Internetrufnummer bei 1und1 registriere habe ich dieses Problem übrigens nicht.
Im Grunde sieht das aus wie dieses Problem hier. Mir ist aber im Augenblick überhaupt nicht klar auf welcher Seite, wo und wann die Sprachpakete verworfen werden und wie ich das herausfinden könnte.
Es wäre schön, wenn mir da mal jemand helfen könnte
Ein paar Infos zu den Fritzboxen:
Fritzbox 1 - Openvpn-Server
192.168.0.0/24 -> eth0 192.168.0.1
10.8.0.0/24 -> tun0 10.8.0.1
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.180.1 0.0.0.0 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 0.0.0.0 255.255.255.255 UH 2 0 0 dsl
131.58.13.234 0.0.0.0 255.255.255.255 UH 2 0 0 dsl
192.168.4.0 10.8.0.4 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 lan
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 0.0.0.0 0.0.0.0 U 2 0 0 dslFritzbox 2 - Openvpn-Client
192.168.4.0/24 -> eth0 192.168.4.4
tun0 10.8.0.4
Internetrufnummer 622 am Sip-Server von FB1 192.168.0.1
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
131.58.13.234 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.178.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 lan
10.8.0.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.0.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lan
0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
128.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
0.0.0.0 192.168.4.1 0.0.0.0 UG 9 0 0 lan
Zuletzt bearbeitet:
Aus der Beschreibung wird nicht ganz deutlich, ob die Client Box auch Server im Internet anpingen und auch anderweitig auf diese zugreifen kann.
Überträgt der Sip-Server in der Box auch selbst die Sprache, oder gibt er nur die Ports der beteiligten jeweils weiter? Im zweiten Fall müßte die Box wissen, daß sie hierfür ein NAT durchführen muß.
Überträgt der Sip-Server in der Box auch selbst die Sprache, oder gibt er nur die Ports der beteiligten jeweils weiter? Im zweiten Fall müßte die Box wissen, daß sie hierfür ein NAT durchführen muß.
Die VoIP-Client-Box ist vermutlich das Porblem, denn wenn ich mich recht erinnere, hat die Box als SIP-Client immer ihre "öffentliche" IP genutzt oder so, jedenfalls war das schon immer problematisch, eine "interne" Verbindung herzustellen. Kannst/hast du die VPN-IP der "VoIP-Serverbox" als SIP-Proxy eingetragen?? Du solltest möglichst versuchen, an allen Stellen die "VPN-IP" zu nutzen (10.8.0.1).
Jörg
Jörg
sbe-michael
Neuer User
- Mitglied seit
- 9 Okt 2010
- Beiträge
- 23
- Punkte für Reaktionen
- 0
- Punkte
- 1
[edit olistudent] Bitte Beiträge editieren!!!
Ja, die Clientbox kann alles anpingen, auch Server im Internet. Ich konnte da bisher keine Einschränkung feststellen. Der Client geht mit der öffentlichen IP-Adresse Serverbox in das Internet. Ich habe die Routingtabellen mal mit in den Beitrag genommen.
Zweiter Absatz: Ich habs nicht ganz verstanden. Aber ich versuche mal zu erklären was die Box tun soll. Meine Serverbox stellt ja einen Sip-Server bereit, an dem ich andere Siptelefone im Netzwerk registrieren kann. In diesem Fall ist das die Clientbox, die die Rufnummer 622 am Sip-Server der Serverbox registriert. Der Sip-Server in der Serverbox soll also die Sprachpakete selbst übertragen.
Das Problem ist aber wohl, dass die Box für die Sprachpakete eine Abkürzung im Routing nimmt. Nämlich über die IP-Adresse des Tunnels. So habe ich das verstanden, sh. Link im Beitrag. Kurzes Zitat von der verlinkten Seite:
Die Problemstellung auf der angegebenen Webseite ist allerdings hier bei meinem Problem nicht ganz zutreffend, da bei mir ja zwischen den beiden Boxen kein weiterer Server (VPN-Server) steht. Ich habe ja nur eine Clientbox die sich an einer Serverbox anmeldet.
Das habe ich jetzt gerade mal ausprobiert. Bringt aber leider auch nichts die 10.8.0.1 als Proxy einzutragen. Ich hatte vorher schon mal getestet, ob ich mich an der 10.8.0.1 auch registrieren kann. Aber auch das bringt nichts.
Nochmal @Jörg: Kann man denn auf der Serverbox (Sip-Server) herausfinden mit welcher IP die Rufnummer 622 registriert wurde?
Ja, die Clientbox kann alles anpingen, auch Server im Internet. Ich konnte da bisher keine Einschränkung feststellen. Der Client geht mit der öffentlichen IP-Adresse Serverbox in das Internet. Ich habe die Routingtabellen mal mit in den Beitrag genommen.
Zweiter Absatz: Ich habs nicht ganz verstanden. Aber ich versuche mal zu erklären was die Box tun soll. Meine Serverbox stellt ja einen Sip-Server bereit, an dem ich andere Siptelefone im Netzwerk registrieren kann. In diesem Fall ist das die Clientbox, die die Rufnummer 622 am Sip-Server der Serverbox registriert. Der Sip-Server in der Serverbox soll also die Sprachpakete selbst übertragen.
Das Problem ist aber wohl, dass die Box für die Sprachpakete eine Abkürzung im Routing nimmt. Nämlich über die IP-Adresse des Tunnels. So habe ich das verstanden, sh. Link im Beitrag. Kurzes Zitat von der verlinkten Seite:
Die Problemstellung auf der angegebenen Webseite ist allerdings hier bei meinem Problem nicht ganz zutreffend, da bei mir ja zwischen den beiden Boxen kein weiterer Server (VPN-Server) steht. Ich habe ja nur eine Clientbox die sich an einer Serverbox anmeldet.
Das habe ich jetzt gerade mal ausprobiert. Bringt aber leider auch nichts die 10.8.0.1 als Proxy einzutragen. Ich hatte vorher schon mal getestet, ob ich mich an der 10.8.0.1 auch registrieren kann. Aber auch das bringt nichts.
Nochmal @Jörg: Kann man denn auf der Serverbox (Sip-Server) herausfinden mit welcher IP die Rufnummer 622 registriert wurde?
Zuletzt bearbeitet von einem Moderator:
sbe-michael
Neuer User
- Mitglied seit
- 9 Okt 2010
- Beiträge
- 23
- Punkte für Reaktionen
- 0
- Punkte
- 1
So, nachdem ich mich nochmal grundsätzlich mit Netfilter und Source NAT auseinandergesetzt habe und mir diesen Thread nochmals genauer angesehen habe, habe ich eine Lösung gefunden. Auf der Serverbox habe ich jetzt folgende Regel eingetragen. Damit funktioniert jetzt auch die Sprachübertragung.
Danke an alle, die geantwortet haben... und damit Ihr Euch auch mit mir freuen könnt, gibts noch ein Foto vom Versuchsaufbau.
Jetzt muss ich nur noch den "Gelöst-Button" finden.
Code:
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to 192.168.0.1Danke an alle, die geantwortet haben... und damit Ihr Euch auch mit mir freuen könnt, gibts noch ein Foto vom Versuchsaufbau.
Jetzt muss ich nur noch den "Gelöst-Button" finden.
KingTutt
Mitglied
- Mitglied seit
- 15 Sep 2005
- Beiträge
- 357
- Punkte für Reaktionen
- 5
- Punkte
- 18
Hallo,
ich habe festgestellt, dass der OpenVPN Server eine Route immer doppelt pushed. Im Logfile sieht das dann so aus:
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 10.0.0.1
OK!
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 192.168.39.0 MASK 255.255.255.0 10.0.0.1
OK!
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 192.168.39.0 MASK 255.255.255.0 10.0.0.1
Hinzufügen der Route fehlgeschlagen: Das Objekt ist bereits vorhanden.
Wenn ich mir in der RudiShell mit 'cat /var/mod/etc/openvpn.conf' die Pushoptionen meiner Server config ansehe,
push "dhcp-option DNS 192.168.39.2"
push "dhcp-option WINS 192.168.39.2"
push "route 10.0.0.0 255.255.255.0"
push "route-gateway 10.0.0.1"
push "route 192.168.39.0 255.255.255.0 10.0.0.1"
push "route-gateway 10.0.0.1"
push "route 192.168.39.0 255.255.255.0"
dann könnte es sein, dass bei der letzten pushoption das Geateway won Windows automatisch ergänzt wird (da schon vorhanden) und daher der Fehler rührt. Habe ich eine Möglichkeit, die letzte Pushoption einmal aus der config zu löschen?
Wenn ich mit der Rudishell die Datei bearbeite, dann ist nach dem Neustart der OpenVPN Dienstes die gelöschte Option immer wieder vorhanden. Auch ein 'modsave flash' hat nicht geholfen. Was mache ich falsch?
ich habe festgestellt, dass der OpenVPN Server eine Route immer doppelt pushed. Im Logfile sieht das dann so aus:
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 10.0.0.1
OK!
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 192.168.39.0 MASK 255.255.255.0 10.0.0.1
OK!
Wed Jun 15 10:08:14 2011 C:\WINDOWS\system32\route.exe ADD 192.168.39.0 MASK 255.255.255.0 10.0.0.1
Hinzufügen der Route fehlgeschlagen: Das Objekt ist bereits vorhanden.
Wenn ich mir in der RudiShell mit 'cat /var/mod/etc/openvpn.conf' die Pushoptionen meiner Server config ansehe,
push "dhcp-option DNS 192.168.39.2"
push "dhcp-option WINS 192.168.39.2"
push "route 10.0.0.0 255.255.255.0"
push "route-gateway 10.0.0.1"
push "route 192.168.39.0 255.255.255.0 10.0.0.1"
push "route-gateway 10.0.0.1"
push "route 192.168.39.0 255.255.255.0"
dann könnte es sein, dass bei der letzten pushoption das Geateway won Windows automatisch ergänzt wird (da schon vorhanden) und daher der Fehler rührt. Habe ich eine Möglichkeit, die letzte Pushoption einmal aus der config zu löschen?
Wenn ich mit der Rudishell die Datei bearbeite, dann ist nach dem Neustart der OpenVPN Dienstes die gelöschte Option immer wieder vorhanden. Auch ein 'modsave flash' hat nicht geholfen. Was mache ich falsch?
In der Tat ist die "route" Zeile auch ohne Ziel identisch zu der Zeile mit Gateway, wenn der Eintrag im Befehl "route-gateway" dieses Gateway setzt...
Das ganze ist vermutlich eine Eigenart (um nicht zu sagen, ein Fehler) in dem Skript, das die Konfig erzeugt.
Gut möglich, dass da zwei Zweige für die "push"-Einträge existieren, die bei bestimmten Einstellungen beide durchlaufen werden.
Vielleicht könntest du mal deine "eigentliche" Freetz-OpenVPN-Konfig posten, aus der dann das OpenVPN-Konfugurationsfile gebaut wird (cat /mod/etc/conf/openvpn.cfg)?
Jörg
Das ganze ist vermutlich eine Eigenart (um nicht zu sagen, ein Fehler) in dem Skript, das die Konfig erzeugt.
Gut möglich, dass da zwei Zweige für die "push"-Einträge existieren, die bei bestimmten Einstellungen beide durchlaufen werden.
Vielleicht könntest du mal deine "eigentliche" Freetz-OpenVPN-Konfig posten, aus der dann das OpenVPN-Konfugurationsfile gebaut wird (cat /mod/etc/conf/openvpn.cfg)?
Jörg
KingTutt
Mitglied
- Mitglied seit
- 15 Sep 2005
- Beiträge
- 357
- Punkte für Reaktionen
- 5
- Punkte
- 18
Hallo Jörg,
cat /mod/etc/conf/openvpn.cfg liefert folgenden output:
export OPENVPN_ADDITIONAL='#'
export OPENVPN_AUTH_TYPE='static#certs'
export OPENVPN_AUTOSTART='#yes'
export OPENVPN_BOX_IP='#10.0.0.1'
export OPENVPN_BOX_MASK='255.255.255.0#255.255.255.0'
export OPENVPN_CIPHER='BF-CBC#BF-CBC'
export OPENVPN_CLIENT2CLIENT='#yes'
export OPENVPN_CLIENTS_DEFINED='#0'
export OPENVPN_CLIENT_INFO='#yes'
export OPENVPN_CLIENT_IPS='#'
export OPENVPN_CLIENT_MASKS='#'
export OPENVPN_CLIENT_NAMES='#'
export OPENVPN_CLIENT_NETS='#'
export OPENVPN_COMPLZO='yes#yes'
export OPENVPN_CONFIG_CHANGED='new#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='#10.0.0.2 10.0.0.9'
export OPENVPN_ENABLED='yes'
export OPENVPN_EXPERT='yes'
export OPENVPN_FLOAT='#'
export OPENVPN_IPV6='#'
export OPENVPN_KEEPALIVE='yes#yes'
export OPENVPN_KEEPALIVE_PING='10#10'
export OPENVPN_KEEPALIVE_TIMEOUT='120#120'
export OPENVPN_LOCAL='#'
export OPENVPN_LOCAL_NET='#192.168.39.0 255.255.255.0'
export OPENVPN_LOGFILE='#'
export OPENVPN_MAXCLIENTS='1#4'
export OPENVPN_MGMNT='#'
export OPENVPN_MODE='server#server'
export OPENVPN_MTU='1500#1500'
export OPENVPN_NO_CERTTYPE='#'
export OPENVPN_OWN_KEYS='#'
export OPENVPN_PARAM_1='#'
export OPENVPN_PARAM_2='#'
export OPENVPN_PARAM_3='#'
export OPENVPN_PORT='#1194'
export OPENVPN_PROTO='udp#tcp'
export OPENVPN_PULL='#'
export OPENVPN_PUSH_DNS='#192.168.39.2'
export OPENVPN_PUSH_WINS='#192.168.39.2'
export OPENVPN_REDIRECT='#'
export OPENVPN_REMOTE='#'
export OPENVPN_REMOTE_IP='#192.168.200.2'
export OPENVPN_REMOTE_NET='#'
export OPENVPN_SHAPER='#'
export OPENVPN_TAP2LAN='#'
export OPENVPN_TLS_AUTH='#'
export OPENVPN_TYPE='tun#tap'
export OPENVPN_UDP_FRAGMENT='#'
export OPENVPN_VERBOSE='3#3'
Dort steht die route bzw. der Parameter LOCAL_NET aus dem vermutlich der config generiert wird nur einmal drin..
Ich muss gestehen, dass ich nicht geschaut habe, ob da in letzter Zeit ein Fix/Pacth im Freetz devel Zweig gewesen ist. Nach der Version unter Freetz habe ich zur Zeit nen "devel-6328" am laufen.
Nachtrag:
Ich habe mal im svn nachgeschaut. Dort ist vor ca. 4 Wochen ein Patch (von Dir?) eingeflossen, der aber wohl nur ein Problem behebt, wenn das default Gateway umgeleitet wird. Zumindest ist Dein Name mit ? erwähnt:
http://freetz.org/changeset/7007/trunk/make/openvpn/files/root/etc/default.openvpn/openvpn_conf
Ob mein Problem damit zusammenhängt kann ich ohne Testen nicht beurteilen...
Nachtrag2:
Ich habe mir mal das Skript im aktuellen SVN trunk angesehen, welches aus der openvpn.cfg die openvpn.conf generiert und dabei die push Einträge verglichen.
cat /mod/etc/conf/openvpn.cfg liefert folgenden output:
export OPENVPN_ADDITIONAL='#'
export OPENVPN_AUTH_TYPE='static#certs'
export OPENVPN_AUTOSTART='#yes'
export OPENVPN_BOX_IP='#10.0.0.1'
export OPENVPN_BOX_MASK='255.255.255.0#255.255.255.0'
export OPENVPN_CIPHER='BF-CBC#BF-CBC'
export OPENVPN_CLIENT2CLIENT='#yes'
export OPENVPN_CLIENTS_DEFINED='#0'
export OPENVPN_CLIENT_INFO='#yes'
export OPENVPN_CLIENT_IPS='#'
export OPENVPN_CLIENT_MASKS='#'
export OPENVPN_CLIENT_NAMES='#'
export OPENVPN_CLIENT_NETS='#'
export OPENVPN_COMPLZO='yes#yes'
export OPENVPN_CONFIG_CHANGED='new#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='#10.0.0.2 10.0.0.9'
export OPENVPN_ENABLED='yes'
export OPENVPN_EXPERT='yes'
export OPENVPN_FLOAT='#'
export OPENVPN_IPV6='#'
export OPENVPN_KEEPALIVE='yes#yes'
export OPENVPN_KEEPALIVE_PING='10#10'
export OPENVPN_KEEPALIVE_TIMEOUT='120#120'
export OPENVPN_LOCAL='#'
export OPENVPN_LOCAL_NET='#192.168.39.0 255.255.255.0'
export OPENVPN_LOGFILE='#'
export OPENVPN_MAXCLIENTS='1#4'
export OPENVPN_MGMNT='#'
export OPENVPN_MODE='server#server'
export OPENVPN_MTU='1500#1500'
export OPENVPN_NO_CERTTYPE='#'
export OPENVPN_OWN_KEYS='#'
export OPENVPN_PARAM_1='#'
export OPENVPN_PARAM_2='#'
export OPENVPN_PARAM_3='#'
export OPENVPN_PORT='#1194'
export OPENVPN_PROTO='udp#tcp'
export OPENVPN_PULL='#'
export OPENVPN_PUSH_DNS='#192.168.39.2'
export OPENVPN_PUSH_WINS='#192.168.39.2'
export OPENVPN_REDIRECT='#'
export OPENVPN_REMOTE='#'
export OPENVPN_REMOTE_IP='#192.168.200.2'
export OPENVPN_REMOTE_NET='#'
export OPENVPN_SHAPER='#'
export OPENVPN_TAP2LAN='#'
export OPENVPN_TLS_AUTH='#'
export OPENVPN_TYPE='tun#tap'
export OPENVPN_UDP_FRAGMENT='#'
export OPENVPN_VERBOSE='3#3'
Dort steht die route bzw. der Parameter LOCAL_NET aus dem vermutlich der config generiert wird nur einmal drin..
Ich muss gestehen, dass ich nicht geschaut habe, ob da in letzter Zeit ein Fix/Pacth im Freetz devel Zweig gewesen ist. Nach der Version unter Freetz habe ich zur Zeit nen "devel-6328" am laufen.
Nachtrag:
Ich habe mal im svn nachgeschaut. Dort ist vor ca. 4 Wochen ein Patch (von Dir?) eingeflossen, der aber wohl nur ein Problem behebt, wenn das default Gateway umgeleitet wird. Zumindest ist Dein Name mit ? erwähnt:
http://freetz.org/changeset/7007/trunk/make/openvpn/files/root/etc/default.openvpn/openvpn_conf
Ob mein Problem damit zusammenhängt kann ich ohne Testen nicht beurteilen...
Nachtrag2:
Ich habe mir mal das Skript im aktuellen SVN trunk angesehen, welches aus der openvpn.cfg die openvpn.conf generiert und dabei die push Einträge verglichen.
- Zeile 111 generiert: push "dhcp-option DNS 192.168.39.2"
- Zeile 114 generiert: push "dhcp-option WINS 192.168.39.2"
- Zeile 123 generiert: push "route 10.0.0.0 255.255.255.0"
- Zeile 137 generiert: push "route-gateway 10.0.0.1"
- Zeile 149 generiert wegen LOCAL_NET: push "route 192.168.39.0 255.255.255.0 10.0.0.1"
Jetzt kommen die Settings wegen dem TAP Device - Zeile 209 generiert erneut: push "route-gateway 10.0.0.1"
- Zeile 212 generiert erneut wegen LOCAL_NET: push "route 192.168.39.0 255.255.255.0"
Zuletzt bearbeitet:
Keine Ahnung, wann das reingekommen ist, es sollte aber auch nicht so dramatisch sein, wenn Optionen "doppelt" drin sind (solange sie sich nicht widersprechen ;-))
Du könntest mal die anhängende Datei als "openvpn_conf" nutzen: Auspacken und auf die Box nach /tmp/flash/openvpn_conf bringen (ggf. noch per "chmod +x" ausführbar machen) und schauen, ob die noch funktioniert und ob sie "besser" ist.
Jörg
Du könntest mal die anhängende Datei als "openvpn_conf" nutzen: Auspacken und auf die Box nach /tmp/flash/openvpn_conf bringen (ggf. noch per "chmod +x" ausführbar machen) und schauen, ob die noch funktioniert und ob sie "besser" ist.
Jörg
KingTutt
Mitglied
- Mitglied seit
- 15 Sep 2005
- Beiträge
- 357
- Punkte für Reaktionen
- 5
- Punkte
- 18
Hallo Jörg,
ich werde die config mal testen. Muss mir nur erst nen Bypass legen, damit ich im Zweifelfall noch wieder an die Box komme. Ich bin kein shell/bash Experte, was mir aber in Deiner config aufgefallen ist: Werden nicht Stringvergleiche in if Abfragen typischerweise mit "==" verglichen? Ein einfaches "=" ist doch eine Zuweisung und damit dann immer true oder?
Und wenn ich Deine config auf der Box habe, reicht dann ein einfacher Neustart des Dienstes oder sind noch weitere Anweisungen erforderlich?
ich werde die config mal testen. Muss mir nur erst nen Bypass legen, damit ich im Zweifelfall noch wieder an die Box komme. Ich bin kein shell/bash Experte, was mir aber in Deiner config aufgefallen ist: Werden nicht Stringvergleiche in if Abfragen typischerweise mit "==" verglichen? Ein einfaches "=" ist doch eine Zuweisung und damit dann immer true oder?
Und wenn ich Deine config auf der Box habe, reicht dann ein einfacher Neustart des Dienstes oder sind noch weitere Anweisungen erforderlich?
Moin,
nein, in einem Test ist "=" nur eine Abfrage, keine Zuweisung, und "$X == $Y" ist in diesem Falle ein Synonym für "$X = $Y" (siehe z.B. hier).
Wenn die Datei im flash ist, ist diese Art der "Erzeugung" dann resetfest (nach einem "modsave") du kannst die Datei aber auch nach /tmp/ kopieren und über die aktuelle Version "drübermounten" (mount -o bind /tmp/openvpn_conf /etc/default.openvpn/openvpn_conf), das ist dann nach einem Reset wieder weg...
Ein "Restart" des Dienstes sollte dann die neue Config bauen.
Mit "sh /tmp/openvpn_conf config.test" (wichtig: die Datei darf dann nur "penvpn_conf" heißen, ohne _tmp am Ende) kannst du auch direkt eine Test-Config erzeugen und vergleichen...
Jörg
nein, in einem Test ist "=" nur eine Abfrage, keine Zuweisung, und "$X == $Y" ist in diesem Falle ein Synonym für "$X = $Y" (siehe z.B. hier).
Wenn die Datei im flash ist, ist diese Art der "Erzeugung" dann resetfest (nach einem "modsave") du kannst die Datei aber auch nach /tmp/ kopieren und über die aktuelle Version "drübermounten" (mount -o bind /tmp/openvpn_conf /etc/default.openvpn/openvpn_conf), das ist dann nach einem Reset wieder weg...
Ein "Restart" des Dienstes sollte dann die neue Config bauen.
Mit "sh /tmp/openvpn_conf config.test" (wichtig: die Datei darf dann nur "penvpn_conf" heißen, ohne _tmp am Ende) kannst du auch direkt eine Test-Config erzeugen und vergleichen...
Jörg
Zur Ergänzung:
In C ist '=' eine Zuweisung und '==' ein Vergleich.
In POSIX test ist '=' ein Vergleich und '==' gar nicht erwähnt. Der Operator '==' ist eine Erweiterung in bash und auch in der Busybox Shell, da dies nicht viel Platz benötigt und manche auch in Shell-Skripten '==' statt '=' nutzen.
In C ist '=' eine Zuweisung und '==' ein Vergleich.
In POSIX test ist '=' ein Vergleich und '==' gar nicht erwähnt. Der Operator '==' ist eine Erweiterung in bash und auch in der Busybox Shell, da dies nicht viel Platz benötigt und manche auch in Shell-Skripten '==' statt '=' nutzen.
Neueste Beiträge
-
FRITZ!Box 7590 - INHAUS - Smart24P1 - 7.90 - Sammelthema- Letzte: Jstessi
-
FRITZ!Box 5590 - INHAUS - Smart24P1 - 7.90 - Sammelthema
- Letzte: flak65
-
Dynamische und feste IP-Adressen
- Letzte: FHill
-
FRITZ!Box 6660 Cable - Inhaus - Smart24P1 - 7.90
- Letzte: fauli
-
[Problem] F!B 6591 Bootloop
- Letzte: KunterBunter
