Tunnel zwischen Fritzbox und OpenVPN-Server nutzen zum surfen

[Gerdchen03]

Manchmal sieht man vor lauter Bäumen den Wald nicht mehr.

Vergiss das aus Beitrag Nr. 58. Ich habe die Fritzbox ja explizit aus dem Tunnel entfernt (ip rule add from $DSLIP prio 30001 table 2). Klar, dass ich nicht per VPN drauf komme.
Nun ergibt sich aber der Fall, dass ich einen Rechner per WOL starten möchte. Dazu gehe ich ja normalerweise auf 192.168.178.1:84. Da ich die Fritzbox jetzt aus dem Tunnel ausgesperrt habe, geht das per VPN natürlich nicht mehr. Mittels DynDNS aber auch nicht. Ich hab jetzt noch AVM-Firewall installiert, und den Port für WOL freigegeben.
Nun, da alles zu laufen scheint, würde ich gerne das UP- und DOWN-Script einrichten. Dazu habe ich die Datei /tmp/flash/openvpn_conf angelegt:

#  OpenVPN 2.1 Config, Fri Sep 20 00:02:28 CEST 2013
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
remote-cert-tls server
tls-auth /tmp/flash/openvpn/static.key 1
remote xxx.xxx.xx.xxx 1194
nobind
pull
redirect-gateway
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
chroot /tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
script-security 2
up /tmp/flash/upscript.sh
down /tmp/flash/downscript.sh

Wenn ich damit aber openvpn starte, erhalte ich dies:

tmp/flash/openvpn_conf: line 2: proto: not found
/tmp/flash/openvpn_conf: line 3: dev: not found
/tmp/flash/openvpn_conf: line 4: ca: not found
/tmp/flash/openvpn_conf: line 5: cert: not found
/tmp/flash/openvpn_conf: line 6: key: not found
/tmp/flash/openvpn_conf: line 7: tls-client: not found
/tmp/flash/openvpn_conf: line 8: remote-cert-tls: not found
/tmp/flash/openvpn_conf: line 9: tls-auth: not found
/tmp/flash/openvpn_conf: line 10: remote: not found
/tmp/flash/openvpn_conf: line 11: nobind: not found
/tmp/flash/openvpn_conf: line 12: pull: not found
/tmp/flash/openvpn_conf: line 13: redirect-gateway: not found
/tmp/flash/openvpn_conf: line 14: tun-mtu: not found
/tmp/flash/openvpn_conf: line 15: mssfix: not found
/tmp/flash/openvpn_conf: line 16: verb: not found
/tmp/flash/openvpn_conf: line 17: cipher: not found
/tmp/flash/openvpn_conf: line 18: comp-lzo: not found
/tmp/flash/openvpn_conf: line 19: keepalive: not found
/tmp/flash/openvpn_conf: line 20: resolv-retry: not found
/tmp/flash/openvpn_conf: line 21: chroot: not found
/tmp/flash/openvpn_conf: line 22: user: not found
/tmp/flash/openvpn_conf: line 23: group: not found
/tmp/flash/openvpn_conf: line 24: persist-tun: not found
/tmp/flash/openvpn_conf: line 25: persist-key: not found
/tmp/flash/openvpn_conf: line 26: script-security: not found
/tmp/flash/openvpn_conf: line 27: up: not found
/tmp/flash/openvpn_conf: line 28: down: not found
Starting openvpn ... failed.
You may get some more hints by starting openvpn w/o "--daemon":
	openvpn --config /mod/etc/openvpn.conf

 

[MaxMuster]

Nun ergibt sich aber der Fall, dass ich einen Rechner per WOL starten möchte. .... Mittels DynDNS aber auch nicht.

Ja, die "Antwort" von dem Gerät würde ja durch den VPN Tunnel gehen. Nur die FB selbst und den einen PC hast du ja über den DSL-Anschluss umgeleitet.

Dazu habe ich die Datei /tmp/flash/openvpn_conf angelegt:

Das ist so nicht korrekt. Diese Datei ist das Skript, was die Config erzeugt, nicht die Config selbst! Bitte lösche die Datei.

Entweder kannst du die zusätzlichen Befehle in der GUI eingeben (mit "Expertenhaken" erscheint unten eine Zeile für zusätzliche Befehle) oder du packst die eigene Config nach "/tmp/flash/openvpn/own_openvpn.conf".

 

[Gerdchen03]

Danke, nun wird das UP-Script verarbeitet. Wenn ich den openvpn-Dienst stoppe, sollte das DOWN-Script ausgeführt werden, aber es kommt zu einem Fehler:

Tue Sep 24 23:51:35 2013 /tmp/flash/downscript.sh tun0 1500 1542 10.8.0.14 10.8.0.13 init            
Tue Sep 24 23:51:35 2013 WARNING: Failed running command (--up/--down): could not execute external program
Tue Sep 24 23:51:35 2013 Exiting due to fatal error

Im Internet habe ich gefunden, dass das i.d.R. ein Syntaxfehler ist, und die erste Zeile falsch ist. Diese ist aber korrekt und lautet: #!/bin/sh

Mit jedem Problem, das gelöst wird, tritt ein neues auf. Ich kann mich jetzt mittels DynDNS mit der Fritzbox und dem einen Rechner verbinden, wie gewünscht. Ich habe die Fritzbox bisher aber auch benutzt, um mich mit VPN von unterwegs einzuloggen, und über die Box zu telefonieren.
Wenn ich openvpn verwende, kann ich mich nicht mehr wie früher über das "normale" VPN mit der Box verbinden. Aber die 192er IP der Fritzbox ist dem openvpn-Netz nicht mehr bekannt. Das bedeutet, ich kann die FritzApp zum telefonieren nicht mehr von unterwegs nutzen. Hast du dazu noch einen Lösungsansatz? Wäre es nicht möglich, statt die FB aus dem Tunnel zu entfernen, ihr beizubringen, dass auch DynDNS durch den Tunnel gehen soll?

 

[MaxMuster]

Ja, es ist nicht einfach, das gebe ich gerne zu.
Aber schließlich behandeln wir hier längst keine FB-spezifischen Probleme mehr sondern machen einen Crashkurs in fortgeschrittener OpenVPN-Anwendung und Advanced-Linux-Routing ;-).


Problem mit dem "down"-Skript ist, dass das bei Auführung mit "chroot" innerhalb des chroot-Verzeichnisses liegen muss. Dafür kannst du das Skript in den Ordner kopieren lassen (da gibt es einen GUI-Punkt, Dateine in das Verzeichnis zu kopieren) und der Pfad muss ggf. angepasst werden. Alternativ, wenn du eine eigene Config nutzt, kannst du das "chroot" weglassen, dan gelten die "echten Pfade".

Die FB sollte auch vom VPN weiterhin problemlos über die VPN-IP zu erreichen sein.

Du könntest noch einen Befehl zum routing hinzufügen, dass das VPN-Netz anders behandelt, um auch von dort die 192-er IP der FB ansprechen zu können:

# lokales bleibt lokal
ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main
# OpenVPN-Netz auch "normal" routen
ip rule add from 192.168.178.0/24 to 10.8.0.0/24 prio 30001 table main

# Ausnahmen (falls "oben" noch mehr hin muss die Prios verschoben)
ip rule add from $DSLIP prio 30101 table 2
ip rule add from $PCIP prio 30102 table 2
ip route replace default dev dsl table 2

Wenn ich deine DynDNS-Frage richtig verstanden habe, möchtest du Dinge, die durch das DynDNS reinkommen "durch den Tunnel" beantworten? Das tust du mit der jetzigen Config m.E. schon. Antwortpakete auf weitergeleitete Ports kommen "aus dem LAN zu einer fremden IP" und werden durch das VPN geroutet.
Den Zustand, dass auch die FB selbst das tut, hattest du zu Anfang (ohne die ip Einträgen): Dann antwortet die FB aber immer mit der "VPN-IP" und Voip usw gehen nicht, wie du gemerkt hast...
Die FB kann nicht unterscheiden, ob sie eine Antwort auf ein per DynDNS hereingekommenes Paket schickt oder sich z.B. am VoIP-Server anmeldet ...
Ein paar Einschränkungen gibt es immer.

 

[Gerdchen03]

Ich fange erst mal mit dem UP- bzw. DOWN-Script an. Um beide Skripte in den Ordner kopieren zu lassen habe ich folgendes im GUI eingetragen:

/var/tmp/flash/openvpn/downscript.sh;/var/tmp/flash/openvpn/upscript.sh

Was genau muss ich nun in die Datei /var/tmp/flash/openvpn/own_openvpn.conf eintragen? Ich hab verschiedene Varianten versucht, aber keine funktioniert. In der own_openvpn.conf steht unter Anderem "chroot /tmp/openvpn", also müssten doch "upscript.sh" und "downscript.sh" eingetragen werden?!
In dem Ordner /tmp/openvpn liegt aber nach dem Starten des Openvpn weder die Datei upscript.sh, noch downscript.sh. Hat das kopieren dann nicht geklappt?
Wenn openvpn auf der Fritzbox läuft, funktioniert der Push Service nicht mehr. Es kommt immer die Meldung DNS-Fehler. Ohne openvpn werden die Mails rausgeschickt.
Das DNS-Problem scheint auch beim VoIP zu bestehen. Anfänglich funktioniert alles, und nach einigen Stunden geht dann die Telefonie nicht mehr. Die Fritzbox meldet:

26.09.13	06:52:46	Dynamic DNS-Fehler: Fehler bei der DNS-Auflösung des Domainnamens
26.09.13	06:52:00	Anmeldung der Internetrufnummer xxxxxxxxxxxxx war nicht erfolgreich. Ursache: DNS-Fehler

 

[MaxMuster]

Die GUI kopiert "komplette Pfade", wenn du also "/var/tmp/flash/openvpn/downscript.sh" angibst, musst du auch genau das angeben (auch wenn das File dann letzlich nach "/tmp/openvpn/var/tmp/flash/openvpn/downscript.sh" kopiert wird, denn "/tmp/openvpn" wird ja durch das chroot als "/" angesehen.


Eventuell macht die FB DNS mit anderer ausgehender IP (192.168.180.x) und das läuft durch den VPN-Tunnel? Die DNS-Server der Provider beschränken sehr oft die Nutzung auf "eigene" Einwahl-IP-Kreise. Das ginge dann nicht über das VPN.
Dazu könntest du auch das noch als Ausnahme definieren:

# Interne IPs immer per "dsl"
ip rule add from 192.168.180.0/24 prio 30103 table 2

Hilft das? Sonst könntest du einen "offenen" DNS eintragen, zum Testen oder auch so (wenn du mit der "Datensammlungswut" von google kein Problem hast) den von Google unter 8.8.8.8:

echo "nameserver 8.8.8.8" > /etc/resolv.conf

 

[Gerdchen03]

OK, das mit dem UP- bzw. DOWN-Script klingt logisch. Ich hab es entsprechend umgesetzt, und das UP-Script läuft auch problemlos. Das DOWN-Script wird aber nicht gestartet. Ich erhalte folgende Meldungen in /var/tmp/debug_openvpn.out, wenn ich den openvpn beende:

Thu Sep 26 20:34:11 2013 event_wait : Interrupted system call (code=4)                                      
Thu Sep 26 20:34:11 2013 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0                                
Thu Sep 26 20:34:11 2013 ERROR: Linux route delete command failed: could not execute external program
Thu Sep 26 20:34:11 2013 /sbin/route del -net xxx.xxx.xxx.xxx netmask 255.255.255.255                 
Thu Sep 26 20:34:11 2013 ERROR: Linux route delete command failed: could not execute external program
Thu Sep 26 20:34:11 2013 /sbin/route del -net 0.0.0.0 netmask 128.0.0.0                              
Thu Sep 26 20:34:11 2013 ERROR: Linux route delete command failed: could not execute external program
Thu Sep 26 20:34:11 2013 /sbin/route del -net 128.0.0.0 netmask 128.0.0.0                            
Thu Sep 26 20:34:11 2013 ERROR: Linux route delete command failed: could not execute external program
Thu Sep 26 20:34:11 2013 Closing TUN/TAP interface                                                   
Thu Sep 26 20:34:11 2013 /sbin/ifconfig tun0 0.0.0.0                                                 
Thu Sep 26 20:34:11 2013 Linux ip addr del failed: could not execute external program                
Thu Sep 26 20:34:11 2013 /var/tmp/flash/openvpn/downscript.sh tun0 1500 1542 10.8.0.14 10.8.0.13 init
Thu Sep 26 20:34:11 2013 WARNING: Failed running command (--up/--down): could not execute external program
Thu Sep 26 20:34:11 2013 Exiting due to fatal error

Wenn ich das Script selbst auf der Konsole starte funktioniert es:

/tmp/openvpn/var/tmp/flash/openvpn/downscript.sh

 

[MaxMuster]

Gibt es denn während OpenVPN läuft die Datei "/tmp/openvpn/var/tmp/flash/openvpn/downscript.sh" und ist die ausführbar?
("ls -l /tmp/openvpn/var/tmp/flash/openvpn/")

 

[Gerdchen03]

Ja, die gibt es und ich kann sie auch auf der Konsole ausführen. Dann tut das Script auch zuverlässig seine Arbeit. und setzt alle Einstellungen wieder zurück

 

[MaxMuster]

Ich nutze das nicht. Vielleicht müsste auch das "sh" noch dort sein ...
Also wäre mein Vorschlag, in der Config (own_openvpn.conf) das chroot auszukommentieren. Geht es dann?

 

[Gerdchen03]

Herauskommentieren von chroot geht auch nicht. Die Fehlermeldung ist aber eine andere:

Thu Sep 26 21:08:22 2013 /var/tmp/flash/openvpn/downscript.sh tun0 1500 1542 10.8.0.14 10.8.0.13 init                                             
ip: RTNETLINK answers: Operation not permitted                                                                                                    
ip: RTNETLINK answers: Operation not permitted                                                                                                    
route: SIOCDELRT: Operation not permitted                                                                                                         
Thu Sep 26 21:08:22 2013 WARNING: Failed running command (--up/--down): external program exited with error status: 1

Wenn ich das richtig interpretiere, dürfen folgende Befehle nicht ausgeführt werden:

ip rule del from $PCIP prio 30002 table 2
ip route del default dev dsl table 2
route del -net 83.169.182.0/24 dev dsl

Update:
Ich konnte das Problem lokalisieren, weiß aber nicht, wie ich es abstelle:
Die Skripte liegen in /var/tmp/flash/openvpn/ und werden von openvpn nach /tmp/openvpn/var/tmp/flash/openvpn/ kopiert (ist so im GUI eingestellt). Ich habe diese Einstellung nun im GUI deaktiviert, und sie "von Hand" in das Verzeichnis /tmp/openvpn/var/tmp/flash/openvpn/ kopiert. Anschließend habe ich die Scriptdateien in /var/tmp/flash/openvpn/ umbenannt, so dass sie von openvpn nicht mehr gefunden werden können. Jetzt wird das UP-Script nicht mehr ausgeführt, weil es nicht mehr gefunden wird! Das heißt also, dass die ganze Zeit die Skripte im Verzeichnis /var/tmp/flash/openvpn/ anstelle /tmp/openvpn/var/tmp/flash/openvpn/ ausgeführt werden. Daher bleibt auch die Fehlermeldung erhalten!

Ändere ich den Pfad in der own_openvpn.conf ab auf /tmp/openvpn/var/tmp/flash/openvpn/downscript.sh, wird die Datei zwar ausgeführt, denn sie wird jetzt ja wieder gefunden, der Fehler "WARNING: Failed running command (--up/--down): could not execute external program" ist aber nach wie vor vorhanden. Es wird also aus irgendeinem Grund nicht erkannt, dass die Datei im chroot liegt.

 

[Gerdchen03]

noch ein mal kurz zusammengefasst was inzwischen geht, und was nicht:
Funktioniert:
- DynDNS und Zugriff auf einen bestimmten Rechner über einen freigegebenen Port (ohne Tunnel)
- per DynDNS einen Rechner im 192er Netz aufwecken
- DOWN-Script läuft nun auch (in own_openvpn.conf "user openvpn", "group openvpn" und "chroot" auskommentiert)
- VoIP von meinem Smartphone aus mit FritzApp aus dem VPN-Netz (in der Fritzbox Telefongeräte -> Anmeldedaten -> Anmeldung aus dem Internet erlauben anklicken)
- Push-Service, Fritzbox kann jetzt auch Mails verschicken, DNS-Fehler beseitigt (statt mail.gmx.net einfach 212.227.17.190 als SMTP-Server eingetragen)

Funktioniert noch nicht:
- VoIP (40 min nach dem Start des openvpn erscheint die Meldung: Anmeldung der Internetrufnummer xxxxxxxxxx war nicht erfolgreich. Ursache: DNS-Fehler. Danach ist keine Nummer mehr registriert)

 

[MaxMuster]

Up- und Down-Skripte werden unterschiedlich behandelt. Das Up-Skript wird (beim ersten Start) vor dem Ausführen vom chroot "gezogen" (bei eventuell späteren Neu-Aufbau wird es im chroot gesucht), das Down-Skript wird immer vor dem Beenden des chroot ausgeführt, mus also immer dort sein.
Mein Vorschlag war zudem nicht ganz durchdacht: Du hast ja auch deinen User geändert (user openvpn / group openvpn) und der User darf keine Änderungen am Routing vornehmen, daher die Fehlermeldung). Also müsstest du das auch noch auskommentieren.

Für Voip über VPN musste man nach meiner Erinnerung noch was in der FritzApp ändern. Hast du das gemacht?
Die Namensauflösung sollte bei einem öffentlichen DNS fünktionieren, denn dann ist es egal ob über DSL oder VPN.
Wenn es natürlich durch das VPN geht, die FB dafür aber eine "unbekannte" IP als Absende-IP nutzt, dann wird es nicht funktionieren (kein NAT, keine Rückroute auf dem Server).
Da müsste man nochmal herausfinden, wie die FB das genau macht, das müsste z.B. ein Logging von Paketen auf dem VPN-Server ermöglichen.

 

[Gerdchen03]

Ich kann nur wieder vielen Dank für deine Hilfe sagen!! Ich müsste dich mal dringend auf ein Bier einladen ;-)
VoIP mit VPN läuft nun gut, und das Downscript tut auch seine Arbeit!
Den Fehler, dass nach ca. 40 min der DNS-Fehler kommt, tritt nun schon einige Stunden nicht mehr auf. Mal abwarten, ob sich das erledigt hat.
Das letzte Problem scheint das mit dem Push-Service zu sein. Die Fritzbox soll die Mail über einen GMX-Server verschicken (andere Server hab ich auch schon getestet). Ich kann pop.gmx.net von der FB aus anpingen und traceroute geht auch. Der Push-Service geht allerdings nicht. in der /etc/resolv.conf ist nameserver 208.67.220.220 eingetragen.

root@fritz:/var/tmp/flash/openvpn# ping pop.gmx.net
PING pop.gmx.net (212.227.17.185): 56 data bytes
64 bytes from 212.227.17.185: seq=0 ttl=55 time=143.166 ms
64 bytes from 212.227.17.185: seq=1 ttl=55 time=119.531 ms
64 bytes from 212.227.17.185: seq=2 ttl=55 time=98.035 ms
^C
--- pop.gmx.net ping statistics ---
5 packets transmitted, 3 packets received, 40% packet loss
round-trip min/avg/max = 98.035/120.244/143.166 ms
root@fritz:/var/tmp/flash/openvpn# traceroute pop.gmx.net
traceroute to pop.gmx.net (212.227.17.185), 30 hops max, 38 byte packets
 1  *  10.8.0.1 (10.8.0.1)  17.378 ms  22.947 ms
 2  xxxxxxxxx.com (xxx.xxx.xxx.xxx)  17.005 ms  20.406 ms  26.070 ms
 3  te0-0-2.g1.blubone.net (178.254.16.25)  16.270 ms  23.347 ms  61.517 ms
 4  te1-4.c1.mk.de (213.172.99.149)  16.800 ms  30.418 ms  35.762 ms
 5  xe0-0-0.5.e3.mk.de (85.220.183.82)  41.698 ms  20.163 ms  *
 6  decix.bb-c.act.fra.de.oneandone.net (80.81.193.123)  192.136 ms  185.030 ms  217.985 ms
 7  te-1-3.bb-c.tp.kae.de.oneandone.net (212.227.120.17)  174.184 ms  139.950 ms  107.104 ms
 8  ae-4.gw-diste.bs.kae.de.oneandone.net (212.227.121.194)  98.879 ms  82.021 ms  42.440 ms
 9  pop.gmx.net (212.227.17.185)  49.577 ms  77.125 ms  73.234 ms

 

[Joe_57]

Der pop-Server ist eigentlich immer nur ein EMail-Empfänger.
Zum Senden sollte man besser den smtp-Server verwenden (SimpleMessageTransferProtocol)

Joe

 

[MaxMuster]

Hattest du die ip-rules um 192.168.180.0 erweitert (Beitrag #66)? Du müsstest "mail.gmx.net" erreichen.
Zur Not könntest du eine der IPs (212.227.17.168 und 212.227.17.190) direkt als Mailserver eintragen.

 

[Gerdchen03]

Sorry, war natürlich blöd. Muss mail.gmx.net heißen. Aber auch hier funktionieren ping und traceroute.
Mein UP-Script sieht so aus:

#!/bin/sh

# Interne IPs immer per "dsl"
ip rule add from 192.168.180.0/24 prio 30103 table 2

# Hier wird der DNS-Server der Fritzbox geändert
echo "nameserver 208.67.220.220" > /etc/resolv.conf

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

# 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

# Route für VoIP
route add -net 83.169.182.0/24 dev dsl

Also die Tips aus Beitrag 66 sind beide bereits enthalten.

Ich hab jetzt als Mailserver 212.227.17.190 eingetragen, und es geht.

Noch eine weitere Frage hätte ich da: Kann man den Zugriff auf das 192er Netz nur bestimmten Clients erlauben?

 

[MaxMuster]

Du kannst das mal "direkt" testen und eine Mail an den "Wegwerf-Mail-Dienst" Mailinator schicken:

echo "Der Mailtext" > /tmp/mail.txt
mailer -s'Betreff' -f'Mir <[email protected]>' -t'Angie <[email protected]>' -m'mailinator.com' -a'user' -w'pass' -i'/tmp/mail.txt'

Um zu sehen, wie das abläuft wäre "strace" auf der Box gut. So sieht das im "entscheidenden" Teil bei mir aus:

[...]
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2adb2000
sendto(4, "C\2\1\0\0\1\0\0\0\0\0\0\nmailinator\3com\0\0\1\0\1", 32, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("[B]192.168.180.1[/B]")}, 16) = 32
clock_gettime(CLOCK_MONOTONIC, {1133379, 554166593}) = 0
poll([{fd=4, events=POLLIN|POLLRDNORM|POLLRDBAND|0x2000}], 1, 1000) = 1 ([{fd=4, revents=POLLIN|POLLRDNORM}])
clock_gettime(CLOCK_MONOTONIC, {1133379, 619854215}) = 0
recvfrom(4, "C\2\201\200\0\1\0\1\0\2\0\0\nmailinator\3com\0\0\1\0\1"..., 512, MSG_TRUNC, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, [16]) = 93
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(2120), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
fcntl(6, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
setsockopt(6, SOL_SOCKET, SO_OOBINLINE, [1], 4) = 0
connect(6, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("207.198.106.56")}, 16) = -1 EINPROGRESS (Operation now in progress)
clock_gettime(CLOCK_MONOTONIC, {1133379, 635522332}) = 0
clock_gettime(CLOCK_MONOTONIC, {1133379, 637897715}) = 0
poll([{fd=4, events=POLLIN|POLLRDNORM|POLLRDBAND|0x2000}, {fd=6, events=POLLPRI|POLLOUT|POLLWRBAND|POLLERR|POLLHUP}], 2, 1000) = 1 ([{fd=6, revents=POLLOUT}])
clock_gettime(CLOCK_MONOTONIC, {1133379, 821009499}) = 0
connect(6, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("207.198.106.56")}, 16) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(2120), sin_addr=inet_addr("192.168.178.1")}, [16]) = 0
[...]

EDIT: Die neue Frage mit der "Beschränkung" (nur bestimmten Clients erlauben) hab ich nicht verstanden...

 

[Gerdchen03]

Nach 40 Minuten sind meine Rufnummern wieder nicht aktiv. Fehler:

Anmeldung der Internetrufnummer xxxxxxxxxxxxx war nicht erfolgreich. Ursache: DNS-Fehler

Das mit dem strace werde ich nachhher testen.

Ich route ja im VPN-Netz das 192er Netz, d.h. jeder Client kann auf das 192er Netz zugreifen. Ich habe aber ein paar Clients, die gar keinen Zugriff auf das 192er Netz haben sollen. Kann ich dieses Routing also für einige Clients "verbieten"?

 

[MaxMuster]

Also: Vorweg eine Frage zum "UP-Script" oben. Dort ist die Ausnahme für 192.168.178.1 nicht mehr enthalten. Die brauchst du, wenn die Pakete der Box per DSL geroutet werden sollen.

Wenn alle Clients ein "redirect-gateway" bekommen, würden sie immer auch dieses Netz erreichen können ("alles" enthält auch dein LAN).

Du kannst z.B. versuchen, auf dem Server mit "iptables" den Zugriff verschiedener Clients auf das Netz verbieten.
Bin aber nicht 100% sicher, ob bei "client-to-client" das überhaupt per iptables beeinflussbar ist.

Ansonsten kannst du ja auch eine zweite OpenVPN Instanz auf dem Server laufen lassen (ohne client-to-client), für die "beschränkten" Clients.