OpenVPN Verbindung mit Heimnetz, aber nicht mit Internet

Tockra

Lt. Commander
Registriert
Dez. 2008
Beiträge
1.058
Hallo Leute,

ich habe meinen server Zuhause neu aufgesetzt und nun habe ich extreme Probleme bei der Installation von Openvpn. Ich schaffe es zwar mich mit über OpenVPN zu verbinden, habe dann allerdings nur Verbindung zum Lan Netzwerk (192.168.178.x ) . Ich hätte aber gerne Internetzugang:

Server:
Code:
dev tun
proto udp
port port
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway def1"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo
duplicate-cn
keepalive 10 120
Client:
Code:
dev tun
client
proto udp
remote ip port
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3
 
Am VPN-Server muss auch IP-Forwarding und ggfs NAT aktiviert sein. Sonst werden a) keine Daten vom VPN in das LAN bzw. zum Gateway/Internet weitergeleitet und b) die Absendeadresse (=VPN-IP) ist dem Router ohne entsprechend konfigurierte Route unbekannt und wird demnach ignoriert.

Anhand der configs vermute ich mal ein Linux-System. Mach am VPN-Server mal folgendes:

IP-Forwarding :
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward

NAT (eth0 = LAN; je nach Konfiguration auch eth1, etc):
Code:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Alternativ zum NAT kann man im Internet-Router auch eine statische Route ins VPN-Subnetz über die LAN-IP des VPN-Gateways eintragen. Die obigen Änderungen sind temporär, das heißt du musst sie permanent machen, wenn es denn funktioniert. Zum Beispiel durch Editieren der /etc/sysctl.conf.
 
Wenn du weiter ins Internet willst muss irgendetwas die Pakete routen. Unter Windows am einfachsten der Routing und RAS Dienst, unter Linux halt die Firewall.
 
Die Frage ist, ob du den Internet Traffice durch deinen VPN Tunnel senden und quasi über den Internetanschluß Zuhause durch den Tunnel surfen möchtest, oder ob du nur bei Anfragen an dein LAN den Tunnel nutzen möchtest und ansonsten über den "lokal verfügbaren" Internetanschluß surfen möchtest.
 
Kleine Anmerkung noch zum Thema VPN:

Ändere unbedingt dein Subnetz im LAN. Wenn du bei einem Kumpel, in einem Hotel oder sonstwo mit deinem Laptop hockst und dort ebenfalls 192.168.178.0/24 benutzt wird, kann es zu Problemen kommen, wenn du zB auf ein NAS zugreifen willst. Der Laptop kann dann nicht unterscheiden zwischen einer lokalen IP (im Hotel, etc) und einer IP in deiner Wohnung und wird dann lokal nach dem NAS suchen.

Wenn man mehrere Netzwerke via VPN verbindet, sollte man möglichst ungewöhnliche Subnetze verwenden.

192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255.255
10.0.0.0 - 10.255.255.255

Da kann man sich austoben. Zum Beispiel 172.23.1.0 /24 oder auch 192.168.234.0 /24. Die Wahrscheinlichkeit, dass man im Hotel-/Kumpel-/Fremd-LAN dieses Subnetz verwendet, ist verschwindend gering. Gerade im deutschen Raum sind aber 192.168.178.0/24 (Fritzbox) sowie 192.168.2.0/24 (Speedports) und die obligatorischen 192.168.1.0/24 bzw 192.168.0.0/24 weit verbreitet. Gefühlt 95% aller Haushalte verwenden eines dieser Subnetze. Alles kein Problem - bis man zwei davon per VPN verbindet...
 
Ich zitiere mal von openvpn.net:
Routing all client traffic (including web-traffic) through the VPN

Overview

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.
In certain cases this behavior might not be desirable -- you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.
Implementation

Add the following directive to the server configuration file:
push "redirect-gateway def1"
If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:
push "redirect-gateway local def1"
Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.
On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.
When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:
push "dhcp-option DNS 10.8.0.1"
will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.
Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:

  • Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
  • Issues exist with respect to pushing DNS addresses to Windows clients.
  • Web browsing performance on the client will be noticably slower.


Wenn es dir nur um "normales" surfen geht, würde ich dies nicht durch den Tunnel machen, da dies in der Regel deutlich langsamer ist. Wenn du allerdings in öffentlichen WLans Dinge wie Onlinebanking oder ähnliches machen möchtest solltest du zumindest dafür den gesammten Traffic durch den Tunnel Routen. Ich habe dafür extra 2 Profile, je nachdem was ich gerade machen möchte.
 
Zuletzt bearbeitet:
Zumindest in dem zitierten Teil steht aber nix vom IP-Forwarding. Ohne das werden die Pakete aber so oder so nicht geroutet, sondern allesamt gedroppt.
 
Moment mal, Handy geht, Laptop nicht? Wie genau ist dein Versuchsaufbau? Wenn du dich von innerhalb deines Netzwerks über die öffentliche IP (oder DDNS) einwählen willst, klappt das nur, wenn der Router das explizit unterstützt. Wenn nicht, dann kann man die öffentliche IP von innen heraus nicht anpingen/verbinden. Das Handy geht vermutlich über die Mobilfunkverbindung und ist somit unabhängig von deinem LAN.

Und wie genau äußert sich "geht nicht"? Was versuchst du? Ping? FTP? Was genau?


Zum Testen des VPNs solltest du über einen separaten Internetzugang gehen. Entweder Nachbar/Kumpel/sonstwo oder zB über den mobilen Hotspot eines Smartphones.

Wenn die Verbindung als solche steht, kannst du mit WireShark, tcpdump, o.ä. explizit nach Traffic sniffen und so siehst du ob die Daten korrekt weitergeleitet werden. Wenn du von außen über das VPN zB einen Windows-PC anpingst, müsste dort bei WireShark irgendwas ankommen. Kommt nichts an, dann bleibt's irgendwo davor hängen, zB im VPN-Server.

Mit tracert/traceroute kann man am Client gucken welchen Weg die Daten nehmen. Normalerweise sollte dort als erstes das VPN-Gateway auftauchen, gefolgt vom Internet-Router.
 
Zuletzt bearbeitet:
Also ich bin in einem anderen Netzwerk. Mit meinem Handy klappt die Verbindung zum VPN Server und auch das Internet. Mit meinem Laptop klappt eben nur die Verbindung zum Server, aber kein Internet. Ich kann mich aber in die Fritzbox via IP einloggen.

€dit: Es scheint so, dass die Adressauflösung das Problem ist. Ich kann google über IP öffnen, aber nicht über URL. Was muss ich verstellen!?

€dit²: Wobei ich google auch nur anpingen kann mit der IP Adresse, aber nicht im Browser aufrufen kann.
 
Zuletzt bearbeitet:
Die grundsätzliche Verbindung stets nur mit Pings auf eine IP testen, zB 8.8.8.8 (google-public-dns). Das ist die eigentliche Verbindung. Bei google.de etc kommt der DNS ins Spiel und man weiß am Ende nicht ob nu die Verbindung an sich nicht geht oder der DNS.

Klappt der Ping auf 8.8.8.8 kann man den DNS testen:

nslookup google.de

bzw.

nslookup google.de 8.8.8.8

bzw.

nslookup google.de die.ip.des.vpn.gateways


Das testet nacheinander den aktiv eingestellten DNS, explizit den google-dns sowie anschließend explizit den potentiell laufenden DNS auf dem VPN-Server. Ich persönlich würde letzteres bevorzugen, weil sonst jede DNS-Abfrage durch den VPN-Tunnel und von dort wieder ins www zum DNS geht. Das kann den Seitenaufbau beim Surfen verlangsamen. Nutzt man den VPN-Server als DNS, kann dieser Anfragen cachen bzw. fragt zunächst bei seinem DNS nach, zB dem heimischen Internet-Router.


Wenn der Client die push-Option für den DNS nicht übernimmt, kann man den DNS auch manuell einstellen. Möchte man 8.8.8.8 nutzen, weil am VPN-Server kein DNS läuft, sollte man vorab sicherstellen, dass 8.8.8.8 auch korrekt über den Tunnel geroutet wird (tracert / traceroute 8.8.8.8). Sonst gehen die DNS-Requests unter Umständen immer ins Host-LAN und der Admin könnte theoretisch deine DNS-Spuren verfolgen.
 
Zuletzt bearbeitet:
Danke für die Details.
Bei mir
klappt ping 8.8.8.8
nslookup google.de klappt nicht
nslookup google.de 8.8.8.8 klappt
nslookup google.de 10.8.0.0 (auch 10.8.0.1 nicht) klappt nicht
nslookup google.de 192.168.178.1 klappt (das ist der Router da wo mein OpenVPN Server läuft)

Was sagt mir das nun!?
 
Zuletzt bearbeitet:
Gib mal bitte noch die zwei Befehle ein und poste den Output hier.

tracert 8.8.8.8
ipconfig /all

Wenn tracert korrekt über das VPN geroutet wird und der Ping klappt, dann ist die Internetverbindung via VPN prinzipiell funktionstüchtig.

Was genau klappte bei den beiden nslookups nicht? Den Output bitte ebenfalls hier posten. "klappt nicht" trägt nicht zur Fehlersuche bei ;)


Der letzte nslookup fragt beispielsweise explizit den VPN-Server als DNS an (obwohl das eigentlich die *.1 sein müsste!!! Bitte prüfen!). Wenn dort kein DNS läuft, ist es klar, dass das fehlschlägt. Nu könnte man auf dem VPN-Server noch bind9 oder dnsmasq als DNS laufen lassen oder man belässt am Client 8.8.8.8 als DNS (der dann wie gesagt auch immer getunnelt wird, aber es gibt schlimmeres..).

Du kannst die DNS-Option auch direkt beim Client in die Config reinschreiben, die muss nicht zwangsläufig gepusht werden (natürlich dann ohne "push" in die config).
 
Zuletzt bearbeitet:
Mit klappt nicht meine ich "connection timed out; no servers could be reached"

Es handelt sich um ein Unix System, somit habe ich kein ipconfig oder tracert. Ich kann höchstens traceroute liefern:
10.8.0.1 -> 192.168.178.1 -> ...

Geht auf jeden Fall raus. Wie gesagt, ping klappt ja auch. Nur nslookup klappt nicht so ganz


Danke für eure Mühe! Habs endlich geschafft.
Scheinbar muss man bei Unix speziell angeben, dass der DNS Server gepusht werden darf.
Habe das was hier steht: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ in die .ovpn gepackt und es hat funktioniert.
 
Zuletzt bearbeitet:
Tockra schrieb:
Mit klappt nicht meine ich "connection timed out; no servers could be reached"

Es handelt sich um ein Unix System, somit habe ich kein ipconfig oder tracert. Ich kann höchstens traceroute liefern:
10.8.0.1 -> 192.168.178.1 -> ...

Geht auf jeden Fall raus. Wie gesagt, ping klappt ja auch. Nur nslookup klappt nicht so ganz

Poste bitte den Output! Man kann nichts damit anfangen, wenn du sagst "nslookup klappt nicht so ganz". Es geht darum welcher DNS-Server aktuell eingestellt ist. Im Output kann man zB sehen welcher DNS gefragt wurde und ob der DNS korrekt vom Server gepusht bzw. vom Client übernommen wurde! Bedenke, dass wir hier nix von dem sehen was bei dir am Bildschirm angezeigt wird. Schwammige Aussagen wie "klappt nicht" sind wenig hilfreich..

*edit
Na gut, hat sich nu erledigt. :)
 
Zurück
Oben