VPN Zugriff auf Internet nicht möglich (sondern nur auf lokale IPs)

Status
Für weitere Antworten geschlossen.

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Hi,

ich habe mir in den vergangenen Tagen das VPN-Paket auf meiner DS415+ eingerichtet (OpenVPN, TCP, Clients den Server-LAN-Zugriff erlauben, Port-Weiterleitung im Router eingerichtet). Ich kann mich auch erfolgreich aus einem externen Netz per VPN mit der DS verbinden; dann kann ich auch - z.B. per Browser - mit der lokalen IP der DS auf diese zugreifen.

ABER: was leider nicht funktioniert ist, mich per VPN zu verbinden und per Browser (oder auch per ping) auf reguläre Webseiten (Google, Wikipedia etc pp) zugreifen. Da kommt einfach keine Antwort zurück.

Könnt ihr mir weiterhelfen, was ich falsch mache? Bin noch blutiger Anfänger in Sachen VPN & Co.
Vielen Dank!


Hier noch openvpn.ovpn Datei:

dev tun
tls-client
remote MyDynDNSName.synology.me 1194
redirect-gateway
pull
proto tcp-client
script-security 2
ca ca.crt
ns-cert-type server
comp-lzo
reneg-sec 0
auth-user-pass
 

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Hallo,

kommt denn die DS ins Internet? Update / Paketverwaltung

Eine Möglichkeit wäre kein korrektes Standard-Gateway auf der DS eingetragen. Für den Verkehr über die DS wäre redirect-gateway zuständig und das hast Du ja CLientseitig eingetragen. Du schreibst Du hast gepingt. Mit einem Namen oder einer IP? Also beipsielsweise ping 8.8.8.8 liefert kein Ergebnis? Da deine Config nicht ganz Standard ist hast Du vieleicht auch Serverseitig etwas angepaßt was dann auf den Clienten gepusht wird?

Ansonsten gibt Dir traceroute bzw. tracert auf der Console Auskunft wie deine Pakete laufen. Hilfreich wären auch ein paar mehr Angaben. Was benutzt Du für einen Clienten. Welche Versionen. Wie sieht das log von OpenVPN aus.

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
kommt denn die DS ins Internet? Update / Paketverwaltung

Ja, problemlos.

Eine Möglichkeit wäre kein korrektes Standard-Gateway auf der DS eingetragen. Für den Verkehr über die DS wäre redirect-gateway zuständig und das hast Du ja CLientseitig eingetragen. Du schreibst Du hast gepingt. Mit einem Namen oder einer IP? Also beipsielsweise ping 8.8.8.8 liefert kein Ergebnis? Da deine Config nicht ganz Standard ist hast Du vieleicht auch Serverseitig etwas angepaßt was dann auf den Clienten gepusht wird?

Also an externen Adressen pinge ich z.B. google.de, faz.de u.ä. an.
Pings auf 8.8.8.8 und ähnliches laufen problemlos und schnell durch.

Was mögliche serverseitige Änderungen betrifft, fällt mir eigentlich nicht wirklich etwas ein. Dort habe ich quasi nur das VPN-Paket installiert, die Einstellungen in dem - recht beschränkten - Interface vorgenommen und weiter nichts.

Als Standard-Gateway auf der DS ist 192.168.2.1 eingetragen.

Ansonsten gibt Dir traceroute bzw. tracert auf der Console Auskunft wie deine Pakete laufen. Hilfreich wären auch ein paar mehr Angaben. Was benutzt Du für einen Clienten. Welche Versionen. Wie sieht das log von OpenVPN aus.

Traceroute gibt bei externen Zielen einfach gar nichts aus...

Bzgl. der Client-Seite: ich habe OpenVPN einfach aus meinen Linux Mint (Debian Edition) Paketquellen installiert.

$ sudo openvpn --version
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_ifconfig_path=/sbin/ifconfig with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='${prefix}/lib/openvpn' with_route_path=/sbin/route with_sysroot=no
git revision: refs/heads/master/1f88813d1b92c414



Danke jedenfalls schon mal für die Antwort!
 

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
Zeig mal ein Foto von Systemsteuerung--->Netzwerk.
Sind die IP-Bereiche(Subnetz) von Homenetz und entferntem Netz unterschiedlich?
Wenn du das Paketzentrum öffnest, werden Pakete angezeigt, WÄHREND du per VPN verbunden bist?
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Zeig mal ein Foto von Systemsteuerung--->Netzwerk.
Sind die IP-Bereiche(Subnetz) von Homenetz und entferntem Netz unterschiedlich?
Wenn du das Paketzentrum öffnest, werden Pakete angezeigt, WÄHREND du per VPN verbunden bist?

Hier ist das Foto: Netzwerk.jpg

Die IP-Bereiche im entfernten Netz unterscheiden sich mit Sicherheit von den lokalen. Das wird erst recht so sein, da ich ständig aus verschiedenen entfernten Netzen per VPN zugreifen werden... von daher ist das vorprogrammiert.

Das Paketzentrum habe ich - wenn mich nicht alles täuscht - gestern auch über VPN verbunden zum Laufen gebracht (derzeit bin ich im LAN an einem anderen Rechner und kann es nicht testen... oder soll ich mich auch im selben LAN mal per VPN verbinden?)
 

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Traceroute gibt bei externen Zielen einfach gar nichts aus...

Was hast Du denn als Ziel angegeben? Eine IP oder eine Domain. Wenn ein Ping zu 8.8.8.8 problemlos läuft würde ich mir den mal per traceroute anschauen ob der überhaupt über das VPN läuft. Vielleicht hast Du ja gar kein Problem mit den Routen über das VPN, sondern ein Problem mit der Namensauflösung. Hier könnte helfen in der Client-Config einen DNS anzugeben. Beispielsweise:

Rich (BBCode):
dhcp-option DNS 8.8.8.8

Als IP kannst Du natürlich auch die deines Routers angeben 192.168.2.1.

Und nach wie vor wäre das Log von OpenVPN hilfreich. Hier finden sich meist Hinweise was schief läuft. Übrigens ist OpenVPN für UDP optimiert. Bei nicht ganz sauberen Verbindungen, was gerade bei Mobilverbindungen der Fall ist, ist das auf jeden Fall die bessere Wahl.

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Okay dann will ich mal ein paar Terminal-Ausgaben beitragen:

$ sudo openvpn openvpn.ovpn
Tue Jan 20 10:51:53 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username:USERNAME
Enter Auth Password:
Tue Jan 20 10:52:01 2015 Attempting to establish TCP connection with [AF_INET]192.168.2.195:1194 [nonblock]
Tue Jan 20 10:52:02 2015 TCP connection established with [AF_INET]192.168.2.195:1194
Tue Jan 20 10:52:02 2015 TCPv4_CLIENT link local: [undef]
Tue Jan 20 10:52:02 2015 TCPv4_CLIENT link remote: [AF_INET]192.168.2.195:1194
Tue Jan 20 10:52:02 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Jan 20 10:52:02 2015 [synology.com] Peer Connection Initiated with [AF_INET]192.168.2.195:1194
Tue Jan 20 10:52:04 2015 TUN/TAP device tun0 opened
Tue Jan 20 10:52:04 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jan 20 10:52:04 2015 /sbin/ip link set dev tun0 up mtu 1500
Tue Jan 20 10:52:04 2015 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Jan 20 10:52:04 2015 Initialization Sequence Completed
Tue Jan 20 10:53:06 2015 [synology.com] Inactivity timeout (--ping-restart), restarting
Tue Jan 20 10:53:06 2015 /sbin/ip addr del dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Jan 20 10:53:06 2015 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jan 20 10:53:11 2015 Attempting to establish TCP connection with [AF_INET]192.168.2.195:1194 [nonblock]
Tue Jan 20 10:53:12 2015 TCP connection established with [AF_INET]192.168.2.195:1194
Tue Jan 20 10:53:12 2015 TCPv4_CLIENT link local: [undef]
Tue Jan 20 10:53:12 2015 TCPv4_CLIENT link remote: [AF_INET]192.168.2.195:1194
Tue Jan 20 10:53:12 2015 [synology.com] Peer Connection Initiated with [AF_INET]192.168.2.195:1194
Tue Jan 20 10:53:15 2015 TUN/TAP device tun0 opened
Tue Jan 20 10:53:15 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jan 20 10:53:15 2015 /sbin/ip link set dev tun0 up mtu 1500
Tue Jan 20 10:53:15 2015 /sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
Tue Jan 20 10:53:15 2015 Initialization Sequence Completed
^CTue Jan 20 10:54:07 2015 event_wait : Interrupted system call (code=4)
Tue Jan 20 10:54:07 2015 /sbin/ip addr del dev tun0 local 10.8.0.10 peer 10.8.0.9
Tue Jan 20 10:54:07 2015 SIGINT[hard,] received, process exiting

Die letzten drei Zeilen treten natürlich erst auf, wenn ich mittels CTRL+C die Verbindung abbreche... soll heißen: Nach dem Start ist die letzte Ausgabe bis zu einer weiteren Interaktion durch mich "Initialization Sequence Completed".


$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *


$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 easy.box (192.168.2.1) 0.660 ms 0.870 ms 1.116 ms

traceroute wikipedia.org
^C
Bei letzterem kommt einfach gar nichts zurück.


Auch die Option "dhcp-option DNS 8.8.8.8" ändert hieran nichts.


Gruß & Danke für die Unterstützung


Ergänzung: Der Volsltändigkeit halber auch noch den Log mit UDP auf Server- & Client-Seite:
$ sudo openvpn openvpn.ovpn
Tue Jan 20 11:02:02 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username:USERNAME
Enter Auth Password:
Tue Jan 20 11:02:10 2015 UDPv4 link local (bound): [undef]
Tue Jan 20 11:02:10 2015 UDPv4 link remote: [AF_INET]192.168.2.195:1194
Tue Jan 20 11:02:10 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Jan 20 11:02:10 2015 [synology.com] Peer Connection Initiated with [AF_INET]192.168.2.195:1194
Tue Jan 20 11:02:13 2015 TUN/TAP device tun0 opened
Tue Jan 20 11:02:13 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jan 20 11:02:13 2015 /sbin/ip link set dev tun0 up mtu 1500
Tue Jan 20 11:02:13 2015 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Jan 20 11:02:13 2015 Initialization Sequence Completed
^CTue Jan 20 11:02:34 2015 event_wait : Interrupted system call (code=4)
Tue Jan 20 11:02:34 2015 /sbin/ip addr del dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Jan 20 11:02:34 2015 SIGINT[hard,] received, process exiting
 
Zuletzt bearbeitet:

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Du bist auch nicht von extern verbunden, sondern befindest dich im lokalen Netz. Dann kann das auch nicht richtig funktionieren.

Rich (BBCode):
Tue Jan 20 10:52:02 2015 TCP connection established with [AF_INET]192.168.2.195:1194

Hier steht im Regelfall die externe IP von dir. Die Du hier im Forum dann auch unkenntlich machen solltest falls Du noch ein weiteres Log posten solltest. Bei internen braucht man das nicht.

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Du bist auch nicht von extern verbunden, sondern befindest dich im lokalen Netz. Dann kann das auch nicht richtig funktionieren.

Rich (BBCode):
Tue Jan 20 10:52:02 2015 TCP connection established with [AF_INET]192.168.2.195:1194

Hier steht im Regelfall die externe IP von dir. Die Du hier im Forum dann auch unkenntlich machen solltest falls Du noch ein weiteres Log posten solltest. Bei internen braucht man das nicht.

Hatte ich ja im vorletzten Beitrag erwähnt, dass ich gerade im LAN bin... dachte, es hilft evtl. trotzdem weiter. Also nochmal die selben Logs posten, sobald ich wieder extern unterwegs bin?

Danke für den Hinweis, wo Anonymisierung anfallen wird ;)
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Also...

Mittels UDP-Protokoll sieht das ganze irgendwie nicht sehr erfolgreich aus:
Rich (BBCode):
$ sudo openvpn openvpn.ovpn 
Wed Jan 21 08:37:44 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
Enter Auth Username:USERNAME
Enter Auth Password:
Wed Jan 21 08:37:53 2015 UDPv4 link local (bound): [undef]
Wed Jan 21 08:37:53 2015 UDPv4 link remote: [AF_INET]IP.ADRESSE
Wed Jan 21 08:38:54 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jan 21 08:38:54 2015 TLS Error: TLS handshake failed
Wed Jan 21 08:38:54 2015 SIGUSR1[soft,tls-error] received, process restarting
Danach geht das ganze wieder von vorne los, zu einem erfolgreichen Abschluss kommt das nie!


Mit TCP sieht es da schon besser aus:
Rich (BBCode):
$ sudo openvpn openvpn.ovpn 
Wed Jan 21 08:45:14 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
Enter Auth Username:USERNAME
Enter Auth Password:
Wed Jan 21 08:45:23 2015 Attempting to establish TCP connection with [AF_INET]IP.ADRESSE:1194 [nonblock]
Wed Jan 21 08:45:24 2015 TCP connection established with [AF_INET]188.99.174.31:1194
Wed Jan 21 08:45:24 2015 TCPv4_CLIENT link local: [undef]
Wed Jan 21 08:45:24 2015 TCPv4_CLIENT link remote: [AF_INET]188.99.174.31:1194
Wed Jan 21 08:45:24 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jan 21 08:45:25 2015 [synology.com] Peer Connection Initiated with [AF_INET]IP.ADRESSE:1194
Wed Jan 21 08:45:28 2015 TUN/TAP device tun0 opened
Wed Jan 21 08:45:28 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jan 21 08:45:28 2015 /sbin/ip link set dev tun0 up mtu 1500
Wed Jan 21 08:45:28 2015 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Wed Jan 21 08:45:28 2015 Initialization Sequence Completed


Jetzt wollte ich wieder die traceroute-Tests machen.
Rich (BBCode):
$ traceroute wikipedia.org
wikipedia.org: Der Name oder der Dienst ist nicht bekannt
Cannot handle "host" cmdline arg `wikipedia.org' on position 1 (argc 1)



Aber da kommt die Härte:
Rich (BBCode):
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  28.520 ms  56.300 ms  56.309 ms
 2  Pascales-iPhone.local (192.168.2.1)  56.317 ms  56.324 ms  56.331 ms
 3  188.99.160.1 (188.99.160.1)  119.549 ms  119.572 ms  119.575 ms
 4  * * *
 5  88.79.14.17 (88.79.14.17)  56.137 ms 88.79.14.9 (88.79.14.9)  56.146 ms 88.79.14.17 (88.79.14.17)  119.409 ms
 6  92.79.212.225 (92.79.212.225)  119.419 ms 92.79.213.113 (92.79.213.113)  48.165 ms 92.79.212.225 (92.79.212.225)  49.089 ms
 7  92.79.213.122 (92.79.213.122)  77.160 ms  77.178 ms 92.79.211.202 (92.79.211.202)  77.337 ms
 8  72.14.219.45 (72.14.219.45)  77.162 ms 72.14.211.99 (72.14.211.99)  77.351 ms 72.14.219.45 (72.14.219.45)  77.149 ms
 9  216.239.46.117 (216.239.46.117)  77.395 ms 216.239.46.115 (216.239.46.115)  77.343 ms 209.85.253.113 (209.85.253.113)  77.226 ms
10  8.8.8.8 (8.8.8.8)  77.262 ms 72.14.238.143 (72.14.238.143)  77.060 ms 216.239.49.235 (216.239.49.235)  77.098 ms
Ich heiße selber nicht Pascal, kenne nicht mal einen Pascal, und besitze auch kein iPhone... :eek:
Die Traceroute-Anfrage hat auch gefühlte Lichtjahre gedauert, ca. 10-15 Min. würde ich schätzen (mein externes Netz ist zwar langsam, aber so langsam dann auch nicht). Was genau mir das jetzt sagt, weiß ich leider nicht...


Um zu testen, dass ich auch wirklich in meinem gewünschten LAN gelandet bin, habe ich mal versucht, per SSH auf meine DiskStation zuzugreifen; das funktioniert problemlos, im richtigen LAN bin ich also gelandet:
Rich (BBCode):
$ ssh root@192.168.2.195
root@192.168.2.195's password: 


BusyBox v1.16.1 (2015-01-07 15:00:45 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

DiskStation>


Auch dieses mal ändert die Option "dhcp-option DNS 8.8.8.8" nichts an dem Verhalten.


Ich hoffe, das hilft irgendwie weiter... :)


ERGÄNZUNG

Der Vollständigkeit halber noch die Angaben, wie ich den Server eingerichtet habe.
VPN-Server-OpenVPN.jpg
Außerdem habe ich natürlich an meinem Router noch den Port 1194 (ebenfalls als 1194) durchgeleitet / freigegeben.


Falls es hilft, hier auch noch die Informationen zu meinem derzeitigen externen Netzwerk. Das ändert sich aber wie gesagt immer wieder und kann deshalb nur als Beispiel für eine von vielen Netzwerkverbindungen dienen:
Netzwerkverbindung.png
 
Zuletzt bearbeitet:

g202e

Benutzer
Mitglied seit
07. Jun 2009
Beiträge
2.293
Punkte für Reaktionen
0
Punkte
82
192.168.2.1 steht bei dir lt. #5 als Standard-Gateway. Du behauptest jedoch das Gerät(welches als Pascals Ei-Phone identifiziert wird!) NICHT zu kennen?
Und das alles, obwohl du dich im selben Netzwerk zu befinden scheinst(192.168.2.195) - wenn das nicht mysteriös ist!
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
192.168.2.1 steht bei dir lt. #5 als Standard-Gateway. Du behauptest jedoch das Gerät(welches als Pascals Ei-Phone identifiziert wird!) NICHT zu kennen?
Und das alles, obwohl du dich im selben Netzwerk zu befinden scheinst(192.168.2.195) - wenn das nicht mysteriös ist!
Also nicht tatsächlich, aber eben per VPN im selben Netzwerk... nur, dass es da keine Verwechslungen gibt ;)

Aber ich finde es auch sehr mysteriös :confused:
 

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Mittels UDP-Protokoll sieht das ganze irgendwie nicht sehr erfolgreich aus:

Vermutlich den Port 1194 nicht für UDP am Router weitergeleitet. Oder aber der Server steht noch auf TCP. Beides Client-Config und Server müssen übereinstimmen. Und natürlich auch die Portweiterleitung.

Rich (BBCode):
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  28.520 ms  56.300 ms  56.309 ms
 2  Pascales-iPhone.local (192.168.2.1)  56.317 ms  56.324 ms  56.331 ms
 3  188.99.160.1 (188.99.160.1)  119.549 ms  119.572 ms  119.575 ms

Das sieht doch erst einmal gut aus. Die Pakete laufen über dein VPN und verlassen dann am Router den Weg ins weite Internet und Du bekommst auch Pakete zurück. Also alles chic.

Ich heiße selber nicht Pascal, kenne nicht mal einen Pascal, und besitze auch kein iPhone... :eek:

Wie schon erwähnt, ist das wohl eher ein Problem mit der Namensauslösung. Wahrscheinlich ist deinem Clientnetz wohl unter der IP ein iPhone bekannt ist. Wenn dem DNS, was bei 8.8.8.8 auf jeden Fall passiert, die IP 192.168.2.1 nicht bekannt ist versucht er es auf anderen Wegen aufzulösen. Netbios, Cache, Hosts etc. Bestätigen das etwas mit der Namensauflösung nicht stimmt tut dies auch diese Meldung

$ traceroute wikipedia.org
wikipedia.org: Der Name oder der Dienst ist nicht bekannt

traceroute versucht hier den Namen wikipedia.org aufzulösen und kann das nicht. Wenn Du anstatt dessen die 91.198.174.192 nimmst dürftest Du auch Wikipedia erreichen.

Auch dieses mal ändert die Option "dhcp-option DNS 8.8.8.8" nichts an dem Verhalten.

Das ist schon etwas komisch, denn hiermit solltest Du den DNS von google ansprechen und auf jeden Fall externe Adressen auflösen können. Wie oben kannst Du den ja auch erreichen. Alternativ kannst Du ja auch mal deinen Router nehmen.

Rich (BBCode):
dhcp-option DNS 192.168.2.1

Das funktioniert dann jedenfalls bei einer Fritzbox dann auch mit der Namsauflösung für den Router. Also das iphone sollte dann auch bei traceroute nicht mehr ausgegeben werden.

Ein Erklärung das die dhcp-option nicht genommen wird, bzw die Namensauflösung nicht korrekt läuft kann ich mir nur in der Clientkonfiguration vorstellen. Und zwar das hier manuell durch irgendwelche Einstellungen diese Option verhindert wird oder aber vieleicht ein jetzt nicht sichtbares Zeichen in deiner Config steht die diese Zeile dann ungültig macht. Beispielsweise ein falscher Zeilenabschluß.

Welchen DNS er aktiv abfragt kann man mit

Rich (BBCode):
nslookup wikipedia.org

auf der Clientseite prüfen. Das dann natürlich nach dem Aufbau der VPN-Verbindung testen ob hier die IP die in der Config unter dhcp-option steht genommen wird. Ist die dhcp-option nicht aktiviert / eingetragen nimmt dein Client trotz VPN immer noch den DNS der im Clientnetz eingetragen ist und versucht den dann aber über dein VPN zu erreichen (sofern keine lokale IP).

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Also dass es ein Problem mit der Namensauflösung ist, leuchtet mir jetzt auch ein. Ich bin auf dem Gebiet aber in etwa das Gegenteil von einem Experten...

Habe das Nachfolgende jetzt alles mit "dhcp-option DNS 192.168.2.1" getestet.


Rich (BBCode):
traceroute 91.198.174.192
läuft - wenn auch langsam - durch.


Der nslookup jedoch bei bestehender VPN-Verbindung nicht (ohne VPN aber problemlos):
Rich (BBCode):
nslookup wikipedia.org
;; connection timed out; no servers could be reached


Wenn ich "91.198.174.192" im Browser aufrufe, dann klappt sogar das - bis zu dem Punkt, wo Wikipedia Informationen von anderen oder subdomains abrufen will (in der Praxis werden also nur ein paar Textzeilen von Wikimedia und ein paar Bilder angezeigt - alles andere kommt eben von Subdomains; aber im Prinzip klappt es also, bis eben wieder andere Domainnamen aufgelöst werden müssen).


Ich bin nach wie vor ratlos, wie ich das Problem lösen kann :(
Ich habe keinen Verdacht, sondern will nur mal nachfragen: könnte mein Router eine / die Fehlerquelle sein? Muss ich dort etwas außer der Portfreigabe einstellen? Es ist eine EasyBox von Vodafone - ich finde sie absolut nicht gut, mir fehlen oft Einstellungsmöglichkeiten oder eine klare Struktur im Menü; aber ich wohne dort nicht alleine, deshalb muss ich mich mit ihr eben erst mal abfinden...
 

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Ich bin nach wie vor ratlos, wie ich das Problem lösen kann :(

Wie schon gesagt, vermute ich ein nicht sichtbares Zeichen in deiner Config, sodas die dhcp-option nicht genommen wird.

Als Alternative könntest Du auch einfach in den Netzwerkeinstellungen deines Clientcomputers als DNS die 8.8.8.8 anstatt der 134.2.200.1 angeben. Das sollte dein Problem auch lösen.

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
Aus dem Web-Interface der DS kann man die "Einstellungen" ja exportieren lassen. Da sollten ja dann eigentlich keine merkwürdigen Zeichen drin sein, die nicht hinein gehören... soll ich das nochmal probieren? Aber eigentlich hatte ich das ja von Anfang an gemacht...

Wie kann denn die 134.2.200.1 das Namens-Auflösungs-Problem lösen?


Vielen Dank auf jeden Fall, dass du / ihr dran bleibt und mir helfen wollt!
 

fpo4711

Benutzer
Mitglied seit
26. Mai 2010
Beiträge
2.772
Punkte für Reaktionen
1
Punkte
0
Aus dem Web-Interface der DS kann man die "Einstellungen" ja exportieren lassen. Da sollten ja dann eigentlich keine merkwürdigen Zeichen drin sein, die nicht hinein gehören... soll ich das nochmal probieren?

Kann jetzt zwar auf keine DS mit 5.1 schauen, bis jetzt war es aber so das die dhcp-option nach dem Export überhaupt nicht aktiviert bzw. vorhanden war. Editieren muß man die in jedem Fall um dort eine IP einzugeben und das Doppelkreuz zu entfernen damit sie aktiviert wird. Da kann man z.Bsp. unter Windows schnell mal den falschen Editor nehmen und schon ist es passiert.

Wie kann denn die 134.2.200.1 das Namens-Auflösungs-Problem lösen?

Nicht diese IP löst das Problem, sondern diese Einstellung dürfte das Problem sein. :) Vieleicht löst die Uni Tübingen wikipedia.org nicht auf um die Studenten wieder an die alt hergebrachten Tugenden wie Bücher zu gewöhnen :D:D

In den Netzwerkeinstellungen deines Clientcomputers unter DNS die 8.8.8.8 eintragen. Falls der auf DHCP steht dann manuell wählen und die IP eintragen. Finde das jetzt nicht welches Betriebsystem Du benutzt aber das sollte zu finden sein. Unter Linux / Mac = Systemeinstellungen / Netzwerk unter Windows = Systemsteuerung / Netzwerk- Freigabecenter.

Gruß Frank
 

silofonari

Benutzer
Mitglied seit
14. Nov 2014
Beiträge
81
Punkte für Reaktionen
0
Punkte
6
So. Wichtiges Update zum Problem:


Heute morgen habe ich einfach nochmal die openvpn.ovpn Datei von meiner DS exportiert, einfach um nochmal "clean" von vorne anzufangen.

Diese sieht folgendermaßen aus (nur Host-Adresse anonymisiert):

Rich (BBCode):
dev tun
tls-client

remote HOST-ADRESSE 1194

# The "float" tells OpenVPN to accept authenticated packets from any address,
# not only the address which was specified in the --remote option.
# This is useful when you are connecting to a peer which holds a dynamic address
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto tcp-client

script-security 2

ca ca.crt

comp-lzo

reneg-sec 0

auth-user-pass

Jetzt bin ich gerade im Zug unterwegs und dachte mir, ich probiere es doch auch einfach mal, mich mit VPN über meinen mobilen Smartphone-Hotspot zu verbinden (also WLAN-Tethering auf Android, den Laptop dann mit diesem WLAN-Hotspot verbinden, dann VPN-Script openvpn.ovpn ausführen). Und siehe da: alles super!! :)

Ich kann mich sowohl per ssh jetzt im LAN (zuhause) auf anderen (lokalen) Computern einloggen, als auch im Browser beliebige Webseiten aufrufen.


Was mich etwas wundert: ich wollte mit meinem VPN eigentlich nicht bzw. nur nachrangig Anonymisierung bezwecken (macht ja auch wenig Sinn, meine DS ist schließlich immer noch mir zuzuordnen) sondern vielmehr eben eine komfortable und halbwegs sichere Möglichkeit zur Verbindung mit dem LAN zuhause herstellen. Trotzdem habe ich mal meine IP-Adresse auf Seiten wie wieistmeineip.de getestet; und die ändert sich nicht, egal ob ich mit oder ohne VPN die Seite aufrufe... ist das normal und ich habe da etwas missverstanden?


Wie dem auch sei: zumindest weiß ich jetzt, dass es mit dem jetzigen Setup funktioniert bzw. funktionieren kann. Denkbar wäre jetzt natürlich noch, dass das Uni-Netz entsprechende Einstellungen hat, die eine VPN-Verbindung nach außen (zumindest mit den Standard-Einstellungen) nicht möglich machen. Ich werde die Verbindung gleich am Montag nochmal in der Uni testen. Falls es dann wieder nicht klappt, wäre ich - spekulativ gerne auch jetzt schon - froh, wenn ihr mich nochmal unterstützen könntet!


Auf jeden Fall vielen Dank bis hierhin schon mal!


P.S. soll ich die vorherige openvpn.ovpn-Datei hier mal zum Vergleich hochladen, damit wir evtl. den früheren Fehler - auch für zukünftige Interessenten - noch aufdecken können? Oder ist das überflüssig?
 

netguru

Benutzer
Mitglied seit
03. Jan 2015
Beiträge
128
Punkte für Reaktionen
0
Punkte
16
eine offtopic Frage:
"Was mich etwas wundert: ich wollte mit meinem VPN eigentlich nicht bzw. nur nachrangig Anonymisierung bezwecken (macht ja auch wenig Sinn, meine DS ist schließlich immer noch mir zuzuordnen) "

Wie ist denn die DS Dir zuzuordnen?
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
13.999
Punkte für Reaktionen
264
Punkte
373
Hallo,
Trotzdem habe ich mal meine IP-Adresse auf Seiten wie wieistmeineip.de getestet; und die ändert sich nicht, egal ob ich mit oder ohne VPN die Seite aufrufe... ist das normal und ich habe da etwas missverstanden?
was bedeutet, daß der Internetverkehr weiterhin über Mobilfunk geht und nicht über Deinen heimischen Internetanschluß. Nimmst Du das # vor redirect-gateway weg dann würde der Internetverkehr über den heimischen Internetanschluß laufen.

Gruß Götz
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat