Gesamten Fritz!Box LAN-Traffic über OpenVPN Tunnel ins Internet routen

Am einfachsten, indem du mit einer Busybox, die das aktiviert hat, ein "ip rule show" machst.
 
so, ich bin nun dazu gekommen und glaube, dass ip wuderbar funktioniert (Ausgabe ohne irgendwelche Anpassungen):
Code:
# ip rule show
# ip route       
192.168.180.1 dev dsl  metric 2 
192.168.180.2 dev dsl  metric 2 
192.168.178.0/24 dev lan  src 192.168.178.1 
192.168.179.0/24 dev guest  src 192.168.179.1 
188.194.250.0/23 dev dsl  metric 2 
169.254.0.0/16 dev lan  src 169.254.1.1 
default dev dsl
was muss ich nun anstatt "./iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -j ROUTE --oif tun0" eingeben?
 
Das sieht nicht so aus, als ob dein Kernel das unterstützt. Das sollte eher so aussehen:
Code:
root@Speedport:/var/mod/root# ip rule show
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
root@Speedport:/var/mod/root#
Dann sollte das in etwa so gehen:
Code:
root@Speedport:/var/mod/root# ip route add default dev tun0 table 2
root@Speedport:/var/mod/root# ip rule add from 192.168.178.0/24 table 2
root@Speedport:/var/mod/root# ip rule show
0:      from all lookup local 
32765:  from 192.168.178.0/24 lookup 2 
32766:  from all lookup main 
32767:  from all lookup default 
root@Speedport:/var/mod/root# 
root@Speedport:/var/mod/root# ip route show table 2
default dev tun0 
root@Speedport:/var/mod/root#
 
Hallo,
ich bräuchte mal eure Hilfe, da ich jetzt nicht so der Netzwerk- und Fritzboxcrack bin ;-) Ich habe eine Fritzbox 7390 mit aktueller Firmware (84.05.50/FritzOs 5.50) und möchte gerne nur einen Client im Netzwerk (einen TV) mit vyprvpn via pptp/ipsec verbinden, ohne irgendwelche tiefgreifenden Modifikationen a la Freetz vorzunehmen. Per telnet ein paar Zeilen hochschieben bekomme ich hin. Vielen Dank im Voraus!
 
Du bist hier falsch. Hier geht es um OpenVPN. PPTP/IPsec wird von der Fritzbox aber genauso wenig unterstützt.
 
Ich habe ein ganz ähnliches Problem. Ich möchte ebenfalls mein gesamten Traffic über ein Tunnel zu ein VPN Server leiten. Dabei fungiert meine FB 7270 (freetz 1.2) als Client. Die Anmeldung am Server klappt auch, nur funktioniert das Routing überhaupt nicht. Ich wälze mich nun schon seit Tagen durch das Forum und versuche meine Lösung zu finden, denn allzu schwer kann es ja nicht sein ;-)

meine openvpn.config auf der FB 7270 (vom anbieter erhalten, zertifikat-pfade angepasst)
Code:
client
dev tun0
proto udp
remote pw.openvpn.ipredator.se 1194
resolv-retry infinite
nobind

auth-user-pass /tmp/flash/openvpn/usrpass

ca /tmp/flash/openvpn/ca.crt

tls-client
tls-auth /tmp/flash/openvpn/static.key
ns-cert-type server

keepalive 10 30
cipher AES-256-CBC
tls-cipher TLSv1:!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH
persist-key
persist-tun
comp-lzo
tun-mtu 1500
mssfix
passtos
verb 3
log /var/tmp/debug_openvpn.out

in der Onlinechanged-CGI habe ich einfach das Skript von der ersten Seite kopiert, um das defaultgateway zu ersetzen.

Route vor OpenVPN:
Code:
root@fritz:/var/mod/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.189.0   0.0.0.0         255.255.255.0   U     0      0        0 guest
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         169.254.2.1     0.0.0.0         UG    0      0        0 dsl

Route nach OpenVPN:
Code:
root@fritz:/var/mod/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
93.182.186.2    169.254.2.1     255.255.255.255 UGH   0      0        0 dsl
93.182.186.0    0.0.0.0         255.255.255.128 U     0      0        0 tun0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.189.0   0.0.0.0         255.255.255.0   U     0      0        0 guest
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         93.182.186.1    128.0.0.0       UG    0      0        0 tun0
128.0.0.0       93.182.186.1    128.0.0.0       UG    0      0        0 tun0
0.0.0.0         169.254.2.1     0.0.0.0         UG    0      0        0 dsl

Code:
root@fritz:/var/mod/root# cat /var/tmp/debug_openvpn.out
Sat Jan 26 14:14:32 2013 OpenVPN 2.2.1 mipsel-linux [SSL] [LZO2] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Jan 25 2013
Sat Jan 26 14:14:32 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Jan 26 14:14:32 2013 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Sat Jan 26 14:14:32 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 14:14:32 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 14:14:32 2013 LZO compression initialized
Sat Jan 26 14:14:32 2013 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Jan 26 14:14:32 2013 Socket Buffers: R=[108544->131072] S=[108544->131072]
Sat Jan 26 14:14:32 2013 RESOLVE: NOTE: pw.openvpn.ipredator.se resolves to 12 addresses
Sat Jan 26 14:14:32 2013 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Jan 26 14:14:32 2013 UDPv4 link local: [undef]
Sat Jan 26 14:14:32 2013 UDPv4 link remote: [AF_INET]93.182.186.2:1194
Sat Jan 26 14:14:32 2013 TLS: Initial packet from [AF_INET]93.182.186.2:1194, sid=90852457 3b706271
Sat Jan 26 14:14:32 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Jan 26 14:14:33 2013 VERIFY OK: depth=1, /C=SE/ST=Bryggland/L=Oeldal/O=Royal_Swedish_Beer_Squadron/OU=Internetz/CN=Royal_Swedish_Beer_Squadron_CA/[email protected]
Sat Jan 26 14:14:33 2013 VERIFY OK: nsCertType=SERVER
Sat Jan 26 14:14:33 2013 VERIFY OK: depth=0, /C=SE/ST=Bryggland/L=Oeldal/O=Royal_Swedish_Beer_Squadron/OU=Internetz/CN=pw.openvpn.ipredator.se/[email protected]
Sat Jan 26 14:14:35 2013 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Jan 26 14:14:35 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 14:14:35 2013 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Jan 26 14:14:35 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 26 14:14:35 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Jan 26 14:14:35 2013 [pw.openvpn.ipredator.se] Peer Connection Initiated with [AF_INET]93.182.186.2:1194
Sat Jan 26 14:14:37 2013 SENT CONTROL [pw.openvpn.ipredator.se]: 'PUSH_REQUEST' (status=1)
Sat Jan 26 14:14:37 2013 PUSH: Received control message: 'PUSH_REPLY,route 93.182.186.2 255.255.255.255 net_gateway,route-gateway 93.182.186.1,redirect-gateway def1,topology subnet,dhcp-option DOMAIN ipredator.se,dhcp-option DNS 93.182.132.32,dhcp-option DNS 93.182.182.93,ip-win32 dynamic,ping 10,ping-restart 60,ifconfig 93.182.186.25 255.255.255.128'
Sat Jan 26 14:14:37 2013 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:8: ip-win32 (2.2.1)
Sat Jan 26 14:14:37 2013 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 26 14:14:37 2013 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 26 14:14:37 2013 OPTIONS IMPORT: route options modified
Sat Jan 26 14:14:37 2013 OPTIONS IMPORT: route-related options modified
Sat Jan 26 14:14:37 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Jan 26 14:14:37 2013 WARNING: potential conflict between --remote address [93.182.186.2] and --ifconfig address pair [93.182.186.25, 255.255.255.128] -- this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)
Sat Jan 26 14:14:37 2013 TUN/TAP device tun0 opened
Sat Jan 26 14:14:37 2013 TUN/TAP TX queue length set to 100
Sat Jan 26 14:14:37 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jan 26 14:14:37 2013 /sbin/ifconfig tun0 93.182.186.25 netmask 255.255.255.128 mtu 1500 broadcast 93.182.186.127
Sat Jan 26 14:14:37 2013 /sbin/route add -net 93.182.186.2 netmask 255.255.255.255 gw 169.254.2.1
Sat Jan 26 14:14:37 2013 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 93.182.186.1
Sat Jan 26 14:14:37 2013 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 93.182.186.1
Sat Jan 26 14:14:37 2013 /sbin/route add -net 93.182.186.2 netmask 255.255.255.255 gw 169.254.2.1
route: SIOCADDRT: File exists
Sat Jan 26 14:14:37 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Sat Jan 26 14:14:37 2013 Initialization Sequence Completed

Ich nutze IPtables/nat um meine Clients hinter dem VPN zu verstecken
Code:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Ich sehe halt mittlerweile den Wald vor lauter Bäumen nicht mehr. Ich weiß nur das wenn OpenVPN läuft weder die FB noch meine Clients nach außen kommt.
 
Was hast du denn versucht zu erreichen? Eine IP oder einen "Namen"?
Erstmal langsam rantasten: Geht ein Ping von der Box auf die Gegenseite (ping 93.182.186.1)?
Geht ein Ping auf die IP von heise.de (ping 193.99.144.80)?

Geht die Namensauflösung (nslookup heise.de)?
 
mit gestartetem openvpn kann ich sowohl heise.de als auch die IP anpingen. die namensauflösung geht also. aber probiere ich das mit ein anderen server wie zb. google.com geht nichts durch. ich bin nun leicht irritiert... der ping zum vpn server geht auch in <1ms durch. also die verbindung steht erstmal.
 
Geht bei anderen Namen die DNS-Auflösung? "Zur Not" kannst du erstmal ohne VPN eine Reihe von Namen in IPs umwandeln und dann sehen, ob du die als IP-Adresse erreichst.
Wenn es nicht klappt, (aber auch mal als Test zu heise, ob das wirklich durs VPN geht)wäre ein "Traceroute" zum Ziel prima ("traceroute <Ziel-IP>").
Ggf. musst du im menuconfig deinen "Level" zumindest auf "Advanced" anheben und bei den "Busybox applets" den Punkt "network tools" anwählen um traceroute in der Busybox zu haben.
 
die traceroute zu heise.de führt über den vpn. aber das ist eigenartiger weise der einzige server den ich erreichen kann. (facebook.com, mail.ru, google.se, yahoo.com etc. gehen nicht) :confused:

Code:
root@fritz:/var/mod/root# traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 38 byte packets
 1  93.182.185.131 (93.182.185.131)  35.412 ms  37.218 ms  33.684 ms
 2  93.182.139.1 (93.182.139.1)  34.449 ms  36.413 ms  34.098 ms
 3  80.67.1.9 (80.67.1.9)  34.120 ms  37.656 ms  33.856 ms
 4  80.67.4.135 (80.67.4.135)  48.115 ms  47.616 ms  50.547 ms
 5  195.69.144.161 (195.69.144.161)  58.214 ms  52.316 ms  53.254 ms
 6  *  *  *
 7  *  *  *
[...]

ich habe vergessen zu erwähnen das ich auch vom client (laptop) heise anpingen kann. Die Traceroute führt vom laptop logischer weise auch über die FB > VPN > heise.de. Es scheint also ein anderes Problem als das routen zu sein...
 
Was ist mit den IPs? Ping/trace auf Google.com IPs?
Code:
joerg@joerg-desktop:~/freetz-trunk$ nslookup google.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	google.com
Address: 173.194.35.161
Name:	google.com
Address: 173.194.35.169
Name:	google.com
Address: 173.194.35.165
Name:	google.com
Address: 173.194.35.174
Name:	google.com
Address: 173.194.35.162
Name:	google.com
Address: 173.194.35.168
Name:	google.com
Address: 173.194.35.164
Name:	google.com
Address: 173.194.35.166
Name:	google.com
Address: 173.194.35.160
Name:	google.com
Address: 173.194.35.167
Name:	google.com
Address: 173.194.35.163

joerg@joerg-desktop:~/freetz-trunk$
 
jetzt kann ich plötzlich auch google.com anpingen... sonst bleibt trotzdem alles beim alten

Code:
root@fritz:/var/mod/root# nslookup google.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      google.com
Address 1: 173.194.44.33 muc03s08-in-f1.1e100.net
Address 2: 173.194.44.34 muc03s08-in-f2.1e100.net
Address 3: 173.194.44.35 muc03s08-in-f3.1e100.net
Address 4: 173.194.44.36 muc03s08-in-f4.1e100.net
Address 5: 173.194.44.37
Address 6: 173.194.44.38 muc03s08-in-f6.1e100.net
Address 7: 173.194.44.39 muc03s08-in-f7.1e100.net
Address 8: 173.194.44.40 muc03s08-in-f8.1e100.net
Address 9: 173.194.44.41 muc03s08-in-f9.1e100.net
Address 10: 173.194.44.46 muc03s08-in-f14.1e100.net
Address 11: 173.194.44.32 muc03s08-in-f0.1e100.net


edit: nach ein neustart von ovpn, kann ich google nun doch nicht mehr erreichen. es scheint sich nach dem wetter zu entscheiden
Code:
root@fritz:/var/mod/root# nslookup google.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'google.com'
 
Zuletzt bearbeitet:
Vielleicht habe ich mich nicht klar genug ausgedrückt. Bitte mach einen Ping/Trace auf eine IP, deren Namensauflösung nicht funktioniert!

Edit oder einen Trace auf irgendeine IP (1.2.3.4 oder 17.18.19.20 oder was auch immer).
Wenn das immer/regelmäßig durch den Tunnel geht, (selbst wenn es die IP letztlich nicht gibt) dann hast du ein Problem mit der Namensauflösung.
 
Zuletzt bearbeitet:
Code:
root@fritz:/var/mod/root# ping google.de
ping: bad address 'google.de'


root@fritz:/var/mod/root# nslookup google.de
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

nslookup: can't resolve 'google.de'


root@fritz:/var/mod/root# traceroute google.de
traceroute: bad address 'google.de'


root@fritz:/var/mod/root# traceroute 1.2.3.4
traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 38 byte packets
 1  93.182.185.40 (93.182.185.40)  35.960 ms  37.483 ms  35.519 ms
 2  93.182.139.1 (93.182.139.1)  37.367 ms  34.691 ms  36.454 ms
 3  80.67.1.9 (80.67.1.9)  34.655 ms  34.323 ms  35.938 ms
 4  80.67.4.135 (80.67.4.135)  49.710 ms  52.355 ms  51.845 ms
 5  195.69.144.247 (195.69.144.247)  78.374 ms  60.734 ms  61.944 ms
 6  209.85.248.118 (209.85.248.118)  50.757 ms  209.85.248.116 (209.85.248.116)  43.997 ms  209.85.248.118 (209.85.248.118)  76.923 ms
 7  209.85.255.72 (209.85.255.72)  47.465 ms  209.85.255.70 (209.85.255.70)  47.541 ms  209.85.255.74 (209.85.255.74)  48.116 ms
 8  209.85.240.29 (209.85.240.29)  51.978 ms  66.066 ms  209.85.243.32 (209.85.243.32)  54.730 ms
 9  72.14.235.91 (72.14.235.91)  131.647 ms  72.14.235.89 (72.14.235.89)  130.909 ms  132.256 ms
10  72.14.236.147 (72.14.236.147)  152.171 ms  72.14.236.99 (72.14.236.99)  131.928 ms  133.500 ms
11  209.85.252.81 (209.85.252.81)  129.731 ms  209.85.252.47 (209.85.252.47)  138.168 ms  209.85.252.81 (209.85.252.81)  130.376 ms
12 
[...]

ich scheine also ein DNS problem zu haben. any ideas?
 
Versuche mal, ob es mit einem "freien" DNS funktioniert (siehe z.B. hier).

Erstmal sehen, was im DNS der Box steht:
cat /etc/resolv.conf

Wenn du den von google ([noparse]8.8.8.8[/noparse]) nutzen willst:

echo "nameserver [noparse]8.8.8.8[/noparse]" > /etc/resolv.conf

Je nach Box kann es sein, dass die Box diesen DNS "nur für sich selbst nutzt", aber nicht für Anfragen der angeschlossenen Geräte.
Dann musst du den DNS ggf. in der GUI eintragen.
 
Vielen Dank! Das war des Rätzels Lösung. Jetzt funktioniert alles wie es soll.

Zwei Kleinigkeiten habe ich allerdings noch. Zum einen finde ich die Option in der AVM GUI für die DNS einträge nicht mehr. Die sind in der neueren Fimrware und "Zugangsdaten" zu finden. Anscheinend gab es diese Option in der 54.04.88 noch nicht. ich kann natürlich ein Skipt schreiben, aber vielleicht gibt es ja noch eine elegantere lösung...
und dann gibt OVPN immernoch ein fehler aus, was zur folge hat das er das booten der FB an dieser steller abbricht und einige Programme nicht lädt. Stoppe ich den OVPN Prozess geht der ladevorgang der anderen Programme weiter und ich kann OVPN nun wieder starten...

Code:
Sun Jan 27 21:15:08 2013 /sbin/ifconfig tun0 93.182.149.69 netmask 255.255.255.128 mtu 1500 broadcast 93.182.149.127
Sun Jan 27 21:15:08 2013 /sbin/route add -net 93.182.149.2 netmask 255.255.255.255 gw 169.254.2.1
Sun Jan 27 21:15:08 2013 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 93.182.149.1
Sun Jan 27 21:15:08 2013 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 93.182.149.1
Sun Jan 27 21:15:08 2013 /sbin/route add -net 93.182.149.2 netmask 255.255.255.255 gw 169.254.2.1
route: SIOCADDRT: File exists
Sun Jan 27 21:15:08 2013 ERROR: Linux route add command failed: external program exited with error status: 1
Sun Jan 27 21:15:08 2013 Initialization Sequence Completed

ich kann mit dem fehler leider nichts anfangen...
 
Beim DNS kann ich nicht weiter helfen.

Wegen des Fehlers:
"route 93.182.186.2 255.255.255.255 net_gateway" und "redirect-gateway def1" vom Server erzeugen beide jeweils eine Hotroute für die Gegenstelle 93.182.186.2 durch das "alte Defaultgateway".
Daher kommt es beim zweiten Mal zur Fehlermeldung "gibt es schon" (route: SIOCADDRT: File exists).

Weil das aber von der Gegenseite kommt (per "push"), kannst du das nicht wirklich ändern...

Du könntest versuchen, das mit "route-nopull" in der Config zu umgehen und das Routing selbst setzen ("redirect-gateway def1").
 
Vor lauter Infos sehe ich den Zusammenhang nicht mehr ... :(

Um die Clients mittels NAT hinter den OpenVPN Tunnel zu verstecken benötige ich iptables in der Form von:

Code:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Im konkreten Fall würde ich das gerne auf einer 7270v2 machen wollen. Da hab ich die 05.22 mit Freetz r9945 drauf.
Die verschiedensten Forenmails deuten jedoch darauf hin, dass dies so mit dieser Firmware nicht mehr klappen tut, sondern nur die 04.xx, die ich jedoch leider nicht mehr greifbar habe außer was ganz uraltes von vor 4 Jahren.

Hat sich das vielleicht mit der kürzlich erschienen Version 05.50 geändert? Vermute mal nein.
Hängt das wie gehabt mit der Kernel Version zusammen und ein Replace Kernel der 05er Firmware bringt die Box gern zum Rebooten?

Heißt das letztlich ich brauch auch nicht weitersuchen in den verschiedensten Threads des Forums?

Oder gehts auch ohne Replace Kernel und hilft hier irgendwie was statisch gelinktes weiter?
 
Völlig richtig, was du hier schreibst, josefb. Mit fw 05.xx wird es nicht klappen, weil nf_kontrack.ko sich nicht laden lässt. auf 04.xx kannst du einfach mit recovery downgraden. Replaced kernel hilft meines Wissens nach auch nicht.
 
Dann sollte das in etwa so gehen:
Code:
root@Speedport:/var/mod/root# ip route add default dev tun0 table 2
root@Speedport:/var/mod/root# ip rule add from 192.168.178.0/24 table 2
root@Speedport:/var/mod/root# ip rule show
0:      from all lookup local 
32765:  from 192.168.178.0/24 lookup 2 
32766:  from all lookup main 
32767:  from all lookup default 
root@Speedport:/var/mod/root# 
root@Speedport:/var/mod/root# ip route show table 2
default dev tun0 
root@Speedport:/var/mod/root#

Hallo, ich habe nun freetz mit replace kernel und ip-Unterstützung drauf und habe auch das vorgehen so, wie oben gemacht: leider ohne Erfolg. "ip rule add from 192.168.178.0/24 table 2" alleine bringt nichts, wenn ich davor noch "ip route add default dev tun0 table 2" ausführe, dann brechen alle Verbindungen zusammen. Ich vermute, dass sich diese Zeile mit "route add default gw 169.254.2.1 dev $DEFAULTROUTEIF" nicht verträgt. Die letzte brauche ich aber, damit openvpn richtig startet. Irgendwie ist die Rehenfolge bei mir falsch oder ich mische 2 Methoden durcheinander. So ist mein startskript (etwas verkürzt):
Code:
DEFAULTROUTEIF="`route -n | sed -n '/^0.0.0.0[[:space:]]\+0.0.0.0/ s/^.*[[:space:]]\([^[:space:]]\+\)$/\1/p'`"
ifconfig $DEFAULTROUTEIF:dsld 169.254.2.1 dstaddr 169.254.2.1
route del default #2> /dev/null 
route add default gw 169.254.2.1 dev $DEFAULTROUTEIF
# Route für VoIP
route add -net  83.169.182.0/24 dev $DEFAULTROUTEIF

./openvpn --config openvpn.config
[kommen viele Ausgaben: keine Fehler]
Danach wie ich oben schon gesagt habe funktioniert alles bis auf die eingehenden Verbindungen (z.B. ftp)
Jetzt gebe ich folgendes ein:
Code:
# ip rule add from 192.168.178.0/24 table 2
# ip rule show
0:      from all lookup local 
32765:  from 192.168.178.0/24 lookup 2 
32766:  from all lookup main 
32767:  from all lookup default
# ip route show table 2
default dev tun0
das bringt nichts und wie ich oben schon gesagt habe, wenn ich davor noch "ip route add default dev tun0 table 2" ausführe bricht alles zusammen. Was mache ich denn falsch?
 
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.