Tunnel zwischen Fritzbox und OpenVPN-Server nutzen zum surfen

Ich hab den vServer nach dem Ändern der /etc/rc.local neu gestartet. Daher sollte nichts weiter aktiv sein.

Ich bin wieder ein Stück weiter. Scheinbar sind die Ports, die ich brauche, auf dem Server gesperrt. Ich kann z.B. Twonkymedia auf dem Port 9600 auf einem Rechner öffnen. Das Webinterface auf Port 80 vom Receiver aber nicht. Das ist komisch, denn Port 80 muss ja offen sein, sonst könnte ich nicht surfen. Das werde ich Morgen mal checken. Ich denke, das wird sich nun auch noch lösen lassen, das kann nicht mehr viel sein.

Ein Punkt aber bleibt noch: Ist es möglich, eine Regel zu erstellen, dass ich einen Rechner, der im 192er Netz hängt, vom Internet aus auf einem Port ansprechen kann, ohne dass der Rechner, der sich im Internet befindet, eine VPN-Verbindung aufbaut?
Ich will z.B. mit meinem mobilen Gerät, das kein OpenVPn kann, von unterwegs Daten auf dem Port 10000 von einem Rechner, der sich Zuhause im 192er Netz befindet, empfangen können. Ich vermute mal das wird nicht gehen, aber vielleicht gibt es ja doch eine Möglichkeit. Früher hatte ich DynDNS und eine Portweiterleitung in der Fritzbox konfiguriert und fertig.

Eine Idee wäre:
Der Rechner im 192er Netz, den ich von Außen erreichen will, bekommt z.B. die IP 192.168.170.24. Könnte ich dann nicht eine route definieren, so dass 192.168.170.0 immer auf einem festgelegten Port mit dem OpenVPN-Server über dsl kommuniziert, anstatt über den Tunnel? So ungefähr: (xxx.xxx.xxx.xxx ist die IP des OpenVPN-Servers)
route add -net -p 10000 xxx.xxx.xxx.xxx/24 dev dsl
 
Zuletzt bearbeitet:
Da gibt es mehrere Möglichkeiten, wobei die von dir genannte nicht so ohne weiteres funktioniert.

Die einfachste wäre wohl eine Portweiterleitung auf dem v-Server (durch das OpenVPN):

iptables -A PREROUTING -t nat -i venet0 -p tcp --dport 1234 -j DNAT --to 192.168.178.50:80
eventuell noch
iptables -A FORWARD -p tcp -d 192.168.178.50 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Um das auf der FB zu machen, müsstest du sicherstellen, dass die Pakete von dem gewünschten Gerät nicht durch den VPN-Tunnel gehen. Da das "normale" Routing immer nur das Ziel ansieht (und dafür hat das OpenVPN eben eine (Default-)Route durch den Tunnel eingerichtet), brauchst du "policy routing", was z.B. die "Absende-IP" berücksichtigt.
Dafür brauchst du Befehle (in der Busybox) aber vor allem einen Kernel, der das unterstützt. Also ohne freetz geht alles andere wohl nicht.
 
Ok, danke für all deine Hilfe! Ich setze mich jetzt doch mal mit Freetz auseinander.
 
So, mittlerweile läuft Freetz 2.0 auf meine Fritzbox, und ich bin kurz vorm Ziel. Ich hab nach deiner Anleitung hier /iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -i tun0 eingegeben, und die Antwort der Fritzbox lautet:
Code:
iptables v1.4.11.1: Couldn't load target `standard':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

iproute2 läuft, der Befehl ip rule show bring folgende Ausgabe:
Code:
root@fritz:/var/mod/root# ip rule show
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default 
root@fritz:/var/mod/root#

Warum bringt iptables diesen Fehler?
 
Sind vielleicht die "iptables-Module" nicht gewählt? Ich nutze für die Defaults immer das Paket "Iptables-CGI", das wählt schonmal ein Standard-Satz an Modulen für iptables selbst und für die Kernel-Module.
 
Danke, das wars.
 
Zuletzt bearbeitet:
Bitte ohne / am Anfang versuchen ("iptables -t ..." statt "/iptables -t ...").
 
Ich hatte es gerade wenige Minuten vor deinem Post bemerkt. Blöder Fehler.
Nun habe ich aus diesem Post von dir folgendes versucht:
Code:
iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -i tun0
ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main
ip rule add from 192.168.178.0/24 prio 31000 table 2
ip route replace default dev tun0 table 2

Leider bekomme ich keine Telefonverbindung, und meine Dyndns-Verbindung zu Fritzbox klappt auch nicht.
 
Was genau möchtest du denn jetzt erreichen? Eine iptables "mangle" Regel ohne "MARK" scheint mir nicht so sinnvoll.

Dann geht der Post davon aus, dass du kein verändertes Default-Routing hast, sondern das Routing wie ohne VPN funktioniert (kein "redirect-gateway"). Sonst würde jetzt alles in den Tunnel geroutet.
 
Ich will im Grunde das gleiche wie radislav erreichen. Ich möchte, dass der Netzverkehr aller meiner Rechner, die an der Fritzbox hängen, durch den Tunnel geht, mein VoIP aber nicht. Soweit hatten wir das ja schon hinbekommen. Zusätzlich möchte ich aber, dass meine Fritzbox über DynDNS erreichbar bleibt, und ich einen speziellen Rechner auf einem Port von außen erreichen kann. Da bin ich ja im Prinzip nicht weiter gekommen, da hierzu Freetz notwendig ist.

Deshalb habe ich alle Änderungen, die wir in den Posts zuvor besprochen haben, wieder rückgängig gemacht und auf meiner Fritzbox Freetz installiert. Die Umsetzung wollte ich genau so machen, wie radislav: Fritzbox mit Freetz, inkl. iptables und openvpn. Ich will jetzt also versuchen, ohne ein verändertes Default-Routing den LAN-Verkehr durch den Tunnel zu leiten.

Das "redirect-gateway" schalte ich im OpenVPN-Server ab, oder kann ich das in den Fritzbox-Einstellunge irgendwie abschalten?
 
Also, du konntest das im Server raus nehmen, oder (wie radislav) mit "route-nopull" im Client das Lernen von Routen verhindern.

Da du aber, wenn ich das recht verstehe, nur die FB selbst und einen PC "anders" routen willst, sollte das (nicht getestet, nur Theorie) so gehen (analog zu diesem Beitrag):
Code:
#!/bin/sh

# IP des DSL-IF, koennte aus dem LAN-Bereich sein! 
DSLIP=$(ifconfig dsl | sed -n '/inet addr/ s/.*inet addr:\([0-9\.]*\) .*/\1/')

# Hier der PC, der vom Internet direkt erreichbar sein soll und NICHT durch das OpenVPN geht
PCIP=192.168.178.50

# alles lokale weiter zur "normalen" Routingtabelle
ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main

# alles vom DSL immer durch das lokale Internet
ip rule add from $DSLIP prio 30001 table 2

# alles vom PC immer durch das lokale Internet
ip rule add from $DSLIP prio 30001 table 2
ip rule add from $PCIP prio 30002 table 2


# In "table 2" das Default-GW auf dsl setzen, 
# oder das eventuell vorhandene dadurch ersetzen
ip route replace default dev dsl table 2
Dabei wird, anders als bei radislav, das DG weiter vom OpenVPN auf tun0 geändert, die "Ausnahmen" werden über die zweite Routingtabelle über das dsl geschickt.
 
Ich erhalte folgende Fehlermeldung:
Code:
root@fritz:/var/mod/root# ip rule add from $DSLIP prio 30001 table 2
ip: invalid argument '30001' to 'ip'
root@fritz:/var/mod/root# ip rule add from $DSLIP prio 30001 table 2
ip: invalid argument '30001' to 'ip'
 
Was ergibt denn "ifconfig dsl" bzw. der komplette Teil mit dem sed dahinter?
 
Code:
root@fritz:/var/mod/root# ifconfig dsl
dsl       Link encap:Point-to-Point Protocol  
          inet addr:192.168.178.1  P-t-P:192.168.178.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:6858 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15166 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:654523 (639.1 KiB)  TX bytes:2109665 (2.0 MiB)

Code:
root@fritz:/var/mod/root# ifconfig dsl | sed -n '/inet addr/ s/.*inet addr:\([0-9\.]*\) .*/\1/'
root@fritz:/var/mod/root#

Also keine Ausgabe
 
Auf die Schnelle setze DSLIP fest auf 192.168.178.1.
 
Es funktioniert soweit, aber eine Sache geht nun nicht mehr: Nachdem ich
ip route replace default dev dsl table 2
eingebe, kann ich von meinem per OpenVPN verbundenen Smartphone nicht mehr in mein internes Netz gelangen. Das Routing scheint dann nicht zu klappen.

Ich habe mal versucht den bisherigen Stand als Up- bzw. Down-Script einzubinden:

Up-Script (/var/tmp/upscript.sh):
Code:
#!/bin/sh

# IP des DSL-IF, koennte aus dem LAN-Bereich sein! 
DSLIP=192.168.178.1

# Hier der PC, der vom Internet direkt erreichbar sein soll und NICHT durch das OpenVPN geht
PCIP=192.168.178.24

# alles lokale weiter zur "normalen" Routingtabelle
ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main

# alles vom DSL immer durch das lokale Internet
ip rule add from $DSLIP prio 30001 table 2

# alles vom PC immer durch das lokale Internet
ip rule add from $PCIP prio 30002 table 2


# In "table 2" das Default-GW auf dsl setzen, 
# oder das eventuell vorhandene dadurch ersetzen
ip route replace default dev dsl table 2

Down-Script (/var/tmp/downscript.sh):
Code:
#!/bin/sh

# Sonderbehandlung für das LAN wieder entfernen
ip rule del from $PCIP prio 30002 table 2
ip rule del from $DSLIP prio 30001 table 2
ip rule del from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main

# und "table 2" wieder löschen
ip route del default dev dsl table 2

Meine openvpn.conf kopiere ich nach /tmp/flash/openvpn_conf und füge dort die Zeilen:
script-security 2
up /var/tmp/upscript.sh
down /var/tmp/downscript.sh

Stimmt das soweit? Wie mache ich diese Dateien Rebootfest?
 
Zuletzt bearbeitet:
Was kannst du nicht erreichen? Die FB selbst ist nur noch per VPN IP erreichbar, der eine PC gar nicht mehr durch das VPN.
 
Über VPN kann ich nach dem Befehl keine 192er IP mehr erreichen. Egal ob FB oder andere Rechner.
 
Hast du die "alten" Befehle (vom Beitrag #48) wieder entfernt, denn da hattest du alles vom LAN auf die "table 2" geroutet?
Siehts du mit "ip rule show".
 
OK, ich bring noch mal Struktur rein :)

server.conf:
Code:
local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/VPN-Server.crt #server.crt
key ./easy-rsa2/keys/VPN-Server.key #server.key    # Diese Datei geheim halten.
dh ./easy-rsa2/keys/dh2048.pem     # Diffie-Hellman-Parameter
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ./logs/ipp.txt
client-config-dir ccd
route 192.168.178.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
client-to-client
keepalive 10 120
tls-auth ./easy-rsa2/keys/ta.key 0 # This file is secret
comp-lzo
max-clients 15
user openvpn
group openvpn
persist-key
persist-tun
status ./logs/openvpn-status.log
log-append  ./logs/openvpn.log
verb 4
crl-verify crl.pem

openvpn.conf:
Code:
client # wir sind Client
dev tun #
remote-cert-tls server
auth-nocache
tls-auth ta.key 1
dev-node /var/tmp/tun # Hier wird das Devide angegeben. wichtig!
proto udp # wir nutzen UDP, kein TCP
remote xxx.xxx.xxx.xxx 1194 # die IP/ DNS Name der Gegenseite und Port
resolv-retry infinite # Namensauflösung immer
nobind # wir brauchen den Port nicht zu binden.
persist-key
persist-tun
ca ./ca.crt # Die Zertifikate (Pfadangabe muss richtig sein)
cert ./client.crt
key ./client.key
dh ./dh2048.pem
comp-lzo # Komprimierung, sofern auf der Gegenseite auch aktiv.
verb 1 # Fuer Debugging ruhig bis 8 hochsetzen.
mute 20 # Nach x Wiederholungen im Log ruhe.

client-config-dir:
Code:
iroute 192.168.178.0 255.255.255.0

/etc/rc.local:
Code:
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -o venet0 -s 192.168.178.0/24 -j SNAT --to xxx.xxx.xxx.xxx

Befehle, die ich derzeit noch selbst, also ohne ein Skript, eingebe:
Code:
DSLIP=192.168.178.1
PCIP=192.168.178.24
ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main
ip rule add from $DSLIP prio 30001 table 2
ip rule add from $PCIP prio 30002 table 2
ip route replace default dev dsl table 2
route add -net 83.169.182.0/24 dev dsl

Die Befehle aus Beitrag 48 sind nicht mehr aktiv. Ich gebe die über ssh ein, und wenn die Box neu startet ist alles vergessen.
 
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.