Probleme bei OpenVPN-Einrichtung auf FB 7320

InfectedChild

Neuer User
Mitglied seit
21 Sep 2011
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Hallo alle miteinander! :)

ich habe mich gestern an der Einrichtung eines OpenVPN Servers auf meiner Fritzbox Fon WLAN 7320 (Firmware-Version 100.04.89) versucht. Das ganze habe ich mit Hilfe dieser Anleitung gemacht --> http://www.wehavemorefun.de/fritzbox/OpenVPN#OpenVPN_Server_auf_einer_Fritzbox

Mit Hilfe eures gelungenen Forums hier (und der SuFu ;)) habe ich auch erste Probleme selbst lösen können.. z.b. habe ich für die 7320 eine andere OpenVPN Binary gebraucht als die in der Anleitung angegeben. Naja, wie auch immer.. nun kommen die ersten Probleme bei denen ich mir mit der SuFu hier nicht helfen konnte:

1. Ich lade via wget brav meine Dateien in /var/tmp/vpn, setze Attribute, verändere die debug.cfg.. wenn ich dann aber meine Box neustarte um zu sehen, ob die Befehle in der debug.cfg einwandfrei ausgeführt werden muss ich immer wieder feststellen, dass der komplette Ordner "vpn" wieder verschwunden ist. Was mache ich da falsch?

2. Wenn ich die Befehle (vor einem Box-Neustart) der debug.cfg manuell eingebe, läuft der Server einwandfrei und ich kann ihn auch aus dem LAN erreichen. Wenn ich aber versuche den Port 1194 auf das Virtuelle eth0:1-Device zu forwarden, dann bekomm ich im Telnet die Meldung, dass das Device mit der IP kein "intern host" sei und die Regel ignoriert wird. Wenn ich das ganze dann von außen teste bekomme ich natürlich ein timeout. :( Warum funktioniert die Weiterleitung nicht?

Hier ein paar Infos:

server.ovpn:
Code:
local 192.168.178.2

port 1194

proto tcp
dev tap0
dev-node /var/tmp/tun

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

ifconfig-pool-persist ipp.txt

client-to-client

keepalive 10 120
comp-lzo

persist-key
persist-tun

verb 3

debug.cfg:
Code:
ifconfig eth0:1 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255 up  
mknod /var/tmp/tun c 10 200
/var/tmp/vpn/openvpn --config /var/tmp/vpn/server.conf --daemon
count=0
while [ $count -le 5 ] &&  ! ifconfig tap0 > /dev/null 2> /dev/null ; do 
        sleep 1
        count=$(( $count + 1 ))
done
ifconfig tap0 192.168.178.3 up
brctl addif lan tap0

..das ist meine erste Modifikation an der Fritzbox, ansonsten wurde noch nichts verändert. brctl musste ich nicht extra nachladen, funktionierte von Anfang an. :)

Ich hoffe ich hab nichts vergessen und ihr könnt mir bei meinen Problemchen helfen! ;)

Vielen Dank im Voraus! :D

Grüße

Karsten
 
Das Laden des Binaries nach /var/tmp/ lädt diese nur ins RAM. Beim Neustart sind die damit wieder weg.
Entweder machst du das Laden bei jedem Neustart (auch über die debug.cfg) oder speicherst die benötigten Dateien auf einem USB-Stick.
 
achso, alles klar.. und die befehle werden erst nach dem verbindungsaufbau ins internet durchgeführt? sonst würden die wget befehle ja nichts funktionieren..
 
Die Befehle werden direkt beim Starten ausgeführt. Das sollte kein Problem sein, wenn du das "wget" auf ein Gerät im LAN machst, beim Laden aus dem Internet müsstest du zunächst prüfen, ob die Internetverbindung bereits steht. Dafür findest du hier sicher einige Beiträge (steht auch irgendwo auf "wehavemorefun"), in etwa läuft das so:

Code:
waitforinet(){
# erster Parameter: Wie oft warten? Standard 5 mal
maxcount=${1-5}
# zweiter Parameter: Wie lange pro Durchlauf warten? Standard 5 sek.
time=${2-5}
#echo "Time=$time Count=$maxcount"
c=1
while !(ping -c 1 google.d >/dev/null 2>&1 || [ $c -gt $maxcount ] ); do 
	sleep $time
	c=$(( $c +1 )) 
done
ping -c 1 google.d >/dev/null 2>&1  && return 0 || return 1
}

# 6 mal 3 Sekunden warten und bei Erfolg laden		
(waitforinet 6 3 && wget .... ) &
 
Super, dann werd ich das mal versuchen, vielen Dank für deine Hilfe! ;)
Wenn ich Probleme hab, meld ich mich noch einmal..

Jetzt habe ich nur noch ein Problem:

2. Wenn ich die Befehle (vor einem Box-Neustart) der debug.cfg manuell eingebe, läuft der Server einwandfrei und ich kann ihn auch aus dem LAN erreichen. Wenn ich aber versuche den Port 1194 auf das Virtuelle eth0:1-Device zu forwarden, dann bekomm ich im Telnet die Meldung, dass das Device mit der IP kein "intern host" sei und die Regel ignoriert wird. Wenn ich das ganze dann von außen teste bekomme ich natürlich ein timeout. Warum funktioniert die Weiterleitung nicht?
 
..wenn ich meine debug.cfg nun durchlaufen lassen möchte, bekomme ich folgende Meldung:

Code:
# ./debug.cfg
'fconfig: bad address '
'knod: invalid number '200
./debug.cfg: line 12: syntax error: end of file unexpected (expecting "done")

..meine debug.cfg sieht so aus:

Code:
mkdir /var/tmp/vpn
mount /dev/sda1 /var/tmp/vpn
ifconfig eth0:1 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255 up  
mknod /var/tmp/tun c 10 200
/var/tmp/vpn/openvpn --config /var/tmp/vpn/server.conf --daemon
count=0
while [ $count -le 5 ] &&  ! ifconfig tap0 > /dev/null 2> /dev/null ; do 
        sleep 1
        count=$(( $count + 1 ))
done
ifconfig tap0 192.168.178.3 up
brctl addif lan tap0

..ich weiß nicht weiter :(
 
Die Originalfirmware bietet IPSEC VPN von Haus aus? Warum fummelst Du an so komplizierten Sachen rum wenn VPN sich mit den Assistenten von AVM viel einfacher realisieren lässt?
 
..warum fliegt der Mensch zum Mond? Da gibt es nicht einmal Luft zum atmen.
 
zum Mond fliegen war ne Dumme Idee. Open VPN auf der FB auch, es sei denn es gibt einen Triftigen Grund.
 
Wenn ich aber versuche den Port 1194 auf das Virtuelle eth0:1-Device zu forwarden ...
Seit vielen Jahren geht das nicht mehr mit einer "virtuellen IP". Das Forwarding muss auf die "alles IP" 0.0.0.0 gemacht werden. Schau dazu mal im Freetz-Wiki zum OpenVPN nach.

'fconfig: bad address '
'knod: invalid number '200

Steht da wirklich "fconfig" und "knod"? Da fehlt immer der erste Buchstabe, prüfe den Inhalt der debug.cfg nochmal.
 
okay, die weiterleitung habe ich eingerichtet, aber noch nicht getestet.. steht jetzt aber genau wie die https-portweiterleitung in der ar7.cfg :)

mit der debug.cfg bin ich auch weiter gekommen, habe die datei mit cat in /var/tmp geholt, dort komplette neu geschrieben und mit cat wieder zurück..
ausführen kann ich sie jetzt nicht mehr, da bekomm ich "permission denied".. aber sie wird ausgeführt, das erkenn ich daran, dass das mounting vom
usb stick da ist. trotzdem habe ich noch ein problem:

der server wird anscheinend garnicht gestartet! wenn ich die box neustarte und versuch den server mit:

Code:
/var/tmp/vpn/openvpn --config /var/tmp/vpn/server.conf

..zu starten, bekomm ich keine fehlermeldung aber unter "ps" taucht er nicht auf.
auch wird keine openvpn.log angelegt. wenn ich aber direkt in /var/tmp/vpn/ wechsle und dort folgendes mache:

Code:
./openvpn --config server.conf

..geht es sofort! warum? :confused:
 
Mit der Config von oben solltes du sehen können, wo es eventuell hakt. Hast du da mittlerweile ein "daemon" drin? Dann kommentiere es ggf aus und versuche es nochmal.
Sonst sollte der ganze Startvorgang (einschließlich eventueller Fehler) zu sehen sein. Es kann ja eigentlich nur ein "Pfad-Problem" sein:
Wenn da z.B. (wie oben) "ca ca.cert" steht, ist das nur innerhalb des Ordners o.k., direkt gestartet muss es ein absoluter Pfad sein ("ca /var/tmp/vpn/ca.cert").
 
Ja, ich habe ziemlich viel probiert, bis es soweit funktionierte.. hier mal die aktuellen Inhalte:

server.conf:

Code:
daemon
local 192.168.178.2
server-bridge 192.168.178.1 255.255.255.0 192.168.178.200 192.168.178.230
port 1194

proto tcp-server
dev tap0
dev-node /var/tmp/tun

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

ifconfig-pool-persist ipp.txt

client-to-client

keepalive 10 120
comp-lzo

persist-key
persist-tun
status openvpn-status.log

log openvpn.log

verb 3

debug.cfg:

Code:
mkdir /var/tmp/vpn
mount /dev/sda1 /var/tmp/vpn
ifconfig eth0:1 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255 up
mknod /var/tmp/tun c 10 200
/var/tmp/vpn/openvpn --config /var/tmp/vpn/server.conf

count=0
while [ $count -le 5 ] && ! ifconfig tap0 > /dev/null 2> /dev/null;
do
sleep 1
count=$(( $count + 1 ))
done

ifconfig tap0 192.168.178.3 up
brctl addif lan tap0

Die Files sind alle auf dem USB Stick und werden auf /var/tmp/vpn gemountet:

ca.crt
dh1024.pem
ipp.txt
openvpn
openvpn-status.log
openvpn.log
server.conf
server.crt
server.key

..demnach stehen in der debug.cfg absolute Pfade, auch im Startbefehl für OpenVPN.
Die debug.cfg ist denke ich in Ordnung, denn ich habe manuell ja auch das Problem:

OpenVPN lässt sich über den absoluten Pfad nicht starten, aus dem Verzeichnis /var/tmp/vpn ohne absoluten Pfad geht es sofort. Und in der debug.cfg brauch ich ja den absoluten Pfad..

Ich hab wie du gesagt hast das "daemon" auskommentiert.. wenn ich es dann mit dem absoluten Pfad robiert habe, bekam ich folgende Meldungen:

Code:
Fri Sep 23 23:04:18 2011 Warning: Error redirecting stdout/stderr to --log file:
 openvpn.log: Read-only file system (errno=30)
Fri Sep 23 23:04:18 2011 OpenVPN 2.1.1 mips-linux [SSL] [LZO2] [EPOLL] built on
Apr 15 2010
Fri Sep 23 23:04:18 2011 NOTE: when bridging your LAN adapter with the TAP adapt
er, note that the new bridge adapter will often take on its own IP address that
is different from what the LAN adapter was previously set to
Fri Sep 23 23:04:18 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or hig
her to call user-defined scripts or executables
Fri Sep 23 23:04:18 2011 Note: cannot open openvpn-status.log for WRITE
Fri Sep 23 23:04:18 2011 Note: cannot open ipp.txt for READ/WRITE
Fri Sep 23 23:04:18 2011 Cannot open dh1024.pem for DH parameters: error:0200100
2:system library:fopen:No such file or directory: error:2006D080:BIO routines:BI
O_new_file:no such file
Fri Sep 23 23:04:18 2011 Exiting

..darauf hin dachte ich, ich müsste die Rechte anpassen, also:

Code:
chmod 0600 /var/tmp/vpn/*

..machte kein Unterschied. :( Dann in /var/tmp/vpn/ gewechselt und dort:

Code:
./openvpn --config server.conf

..und er läuft. Hat das benutzen des absoluten Pfads auswirkungen auf die Rechte? :confused:
 
Soooo.. es läuft! :D
Das Problem zuletzt konnte ich mit dem Parameter "--cd /var/tmp/vpn" lösen. ;)
Damit die Portweiterleitung funktioniert musste ich natürlich noch ein paar Änderungen vornehmen.. im großen und ganzen sieht meine funktionierende Konfiguration für die FB Fon WLAN 7320 ("1und1 Homeserver") jetzt so aus:

USB Stick (FAT32) mit folgenden Dateien an der FB:

ca.crt
dh1024.pem
openvpn
openvpn-status.log
openvpn.log
server.conf
server.crt
server.key

Eine für die 7320 funktionierende Binary habe ich von hier: http://www.ip-phone-forum.de/showthread.php?t=210107&page=2

Einmalig:
Code:
mkdir /var/tmp/vpn
mount /dev/sda1 /var/tmp/vpn
chmod 0600 /var/tmp/vpn/*
chmod +x /var/tmp/vpn/openvpn

Die Dateien /var/flash/debug.cfg und /var/flash/ar7.cfg angepasst:

debug.cfg:
Code:
mkdir /var/tmp/vpn
mount /dev/sda1 /var/tmp/vpn
mknod /var/tmp/tun c 10 200

/var/tmp/vpn/openvpn --cd /var/tmp/vpn --config /var/tmp/vpn/server.conf --daemon

count=0
while [ $count -le 5 ] && ! ifconfig tap0 > /dev/null 2> /dev/null;
do
sleep 1
count=$(( $count + 1 ))
done
ifconfig tap0 192.168.178.2 up
brctl addif lan tap0

ar7.cfg:
Code:
forwardrules = "tcp 0.0.0.0:443 0.0.0.0:443 0",
                      "tcp 0.0.0.0:1194 0.0.0.0:1194 0 # OpenVPN";

Die Anpassungen habe ich auf diese Art und Weise durchgeführt:

Code:
cat /var/flash/debug.cfg > /var/tmp/debug.cfg
vi /var/tmp/debug.cfg
cat /var/tmp/debug.cfg > /var/flash/debug.cfg

..und meine server.conf:

Code:
local 192.168.178.1
server-bridge 192.168.178.1 255.255.255.0 192.168.178.200 192.168.178.230
port 1194
proto tcp-server
dev tap0
dev-node /var/tmp/tun
tls-server
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 3

..so startet der Server automatisch und ich kann mich über meine DynDNS-Adresse verbinden. Leider konnte ich das noch nicht von außen testen.. werde mich nochmal melden sobald ich das gemacht habe! ;)
 
Zuletzt bearbeitet:
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.