OpenVPN - falsche Routing-Einstellungen?

C

chief654

Gast
Hallo, ich habe einen Server, auf dem ich einen OpenVPN-Server eingerichtet habe. Meine server.conf sieht wie folgt aus:

Code:
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#push "redirect-gateway"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

Die Zeile push "redirect-gateway" habe ich bewusst auskommentiert, da ich keine Internetverbindung habe, wenn ich mit dem VPN-Server verbunden bin. So, nun habe ich erfolgreich eine Internetverbindung, jedoch wird die reale IP-Adresse angezeigt. In verschiedenen Quellen wurde berichtet, dass man dazu das von mir Auskommentierte drinnen lassen sollte. Ich denke, dass das insofern auch funktioniert, da er dann versucht, den Verkehr über den Router des Servers zu routen, dann das Ganze aber nicht in's Internet weitergeleitet wird, warum auch immer.

So, nun die Frage; was genau muss man bei dem Routing beachten und gegebenenfalls einstellen?
 
push "redirect-gateway def1"


From the OpenVPN docs "def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway."

Ums Serverseitige routing und iptables hast dich auch gekümmert?
 
Zuletzt bearbeitet:
Das mit redirect def1 habe ich schon ausprobiert, jedoch erfolglos. Mit iptables habe ich nur einen Befehl ausgeführt - und zwar iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Was man beim Routing noch serverseitig ändern kann/könnte, weiß ich leider nicht.
 
habe ich bewusst auskommentiert, da ich keine Internetverbindung habe, wenn ich mit dem VPN-Server verbunden bin. So, nun habe ich erfolgreich eine Internetverbindung, jedoch wird die reale IP-Adresse angezeigt.
Klar wenn du das Gateway pushst hast du erst INternet wenn dein Server auch entsprechend routet. Der VPN Server selbst macht das nicht
 
chief654 schrieb:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Was man beim Routing noch serverseitig ändern kann/könnte, weiß ich leider nicht.

Das passt erstmal sofern eth0 auch die Netzwerkkarte ist über welche dein Server ans Netz geht. Was für ein OS nutzt du am Server?

Normalerweise ist routing standardmäßig deaktiviert. Unter Debian/Ubuntu z.B. muss das Routing noch aktiviert werden

Code:
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1

Im Anschluss sollte mit redirect-gateway def1 auf jedenfall der Ping zu z.B. 8.8.8.8 gehen.
 
Habe nun beide Befehle ausgeführt und noch das def1 hinzugefügt. Der Ping zu 8.8.8.8 klappt ebenfalls, jedoch keine anderen Funktionen, wie z.B. apt-get update. Da bleibt es immer bei 0 %. Andere Seiten anpingen klappt auch nicht, einfach keine Rückmeldung. Server- und clientseitig läuft bei mir Debian 8.

//EDIT
Anzumerken ist, dass der Client in einer virtuellen Maschine läuft. Die Netzwerkkonfiguration ist eine Netzwerkbrücke. Auf dem Host, ein Windows 7 System, läuft alles einwandfrei, denn da bekomme ich die Server-IP zugewiesen, wenn ich mich mit dem VPN verbinde. Jetzt ist die Frage; liegt es am Linux-Client, wobei man noch etwas beachten muss, oder daran, dass es in einer VM läuft?

//EDIT Ich habe es weitestgehend gelöst, indem ich in VirtualBox Netzwerkbrücke auf NAT umgestellt habe und bei Adapter habe ich Paravirtualistiertes Netzwerk ausgewählt. Wenn ich nun auf dem Host eine aktive VPN-Verbindung habe, habe ich diese automatisch in der VM. Klappt alles super- ist zwar nicht die eleganteste Lösung, aber sie funktioniert. Wenn jemand bessere Lösungsansätze hat, kann er sie ja gerne hier posten ;)
 
Zuletzt bearbeitet:
Ist schon ne Zeitlang her das ich das letzte mal Virtualbox in der Hand hatte. Normalerweise müsste das alles "out of the box" laufen in der vm sofern der Netzwerkadapter auf bridge steht.

Auf die schnelle habe ich jedenfalls keine Idee wieso der Ping zu 8.8.8.8 funktioniert und zu anderen IP Adressen nicht. Oder hast du versucht einen DNS-Namen zu Pingen? Wenn letztes der Fall ist hast du wohl Probleme bei der Namensauflösung. Dann wäre der nächste versuch ob du deinen gepushten DNS Server pingen kannst und ob dieser auch richtig gesetzt wurde.

Code:
ping 208.67.222.222
nslookup google.de

Hast du multiple IP Adressen am Server auf Interface eth0? Wenn ja, könnte das evtl. das Problem sein. Ich nutz dafür in meiner VPN VM folgendes um eine feste Ausgehende IP festzulegen.

Code:
iptables -t nat -A POSTROUTING -s 192.168.170.0/24 ! -d 192.168.0.0/16 -o eth0 -j SNAT --to-source 178.x.x.x
 
Zuletzt bearbeitet:
Ping zu 8.8.8.8 funktioniert, aber zu "anderen Seiten" nicht. 8.8.8.8 ist keine "Seite", sondern eine IP. Wenn man dich also wörtlich nimmt, dann vergleichst du einen Ping auf 8.8.8.8 mit zB einem Ping auf computerbase.de?

Der Unterschied mag für den Laien schwierig zu erkennen sein, aber eine IP und eine "Seite" bzw. Domain sind zwei Paar Schuhe. Grundsätzlich arbeiten Netzwerke und auch das Internet mit IP-Adressen. Domains sind lediglich Platzhalter, die vom DNS (Domain Name Server/Service) in IP-Adressen übersetzt werden. Wenn also ein Ping auf eine IP klappt, aber auf eine Domain nicht, dann ist der DNS der Übeltäter, da die IP-Verbindung ja prinzipiell funktioniert!

Wie von @Harrdy schon geschrieben, mach mal ein paar Tests und poste die Ergebnisse hier (zB per Screenshot)

Code:
ping 8.8.8.8
tracert 8.8.8.8
nslookup computerbase.de
nslookup computerbase.de 8.8.8.8

Mit den Resultaten können wir dann besser beurteilen woran es hapert.
 
Raijin schrieb:
Ping zu 8.8.8.8 funktioniert, aber zu "anderen Seiten" nicht. 8.8.8.8 ist keine "Seite", sondern eine IP. Wenn man dich also wörtlich nimmt, dann vergleichst du einen Ping auf 8.8.8.8 mit zB einem Ping auf computerbase.de?
Naja, das habe ich nicht so gemeint, habe wohl mehr oder weniger unabsichtlich das Wort "anderen" eingebaut, oder ich habe das falsch assoziiert.

Wie von @Harrdy schon geschrieben, mach mal ein paar Tests und poste die Ergebnisse hier (zB per Screenshot)

Code:
ping 8.8.8.8
tracert 8.8.8.8
nslookup computerbase.de
nslookup computerbase.de 8.8.8.8

Mit den Resultaten können wir dann besser beurteilen woran es hapert.

So, habe das nun während der VPN-Verbindung gemacht, hier ist das Ergebnis:

Unbenannt.png

In /etc/openvpn/server.conf habe ich bei push "dhcp-option" DNS x.x.x.x" auch schon den Google-DNS Server eingetragen, jedoch hat das keinen Unterschied gebracht.
 
Zuletzt bearbeitet:
Wie in der CMD zu lesen ist, beim zweiten Befehl ist keine Namensauflösung möglich. Beim 3. hast du den DNS Server als 3. parameter übergeben und die Namensauflösung hat geklappt. Heißt: Die Verbindung funktioniert. Lediglich die Namensauflösung nicht.

Nun könntest du am OpenVPN Client das Debugging einschalten (war glaub verb 4) und schauen was für einen Fehler/Meldung du beim Push des DNS Servers bekommst.

Bzw. mal ein
Code:
cat /etc/resolv.conf
wenn die VPN Verbindung steht. Dort sollte dann der DNS Server drin stehen.
 
Zuletzt bearbeitet:
In Ordnung, wenn ich das richtig verstanden habe sollte in resolv.conf der DNS des VPN's stehen, während die Verbindung aktiv ist? Denn das ist nämlich nicht so, denn dort steht der DNS meines Routers drinnen.
 
Zurück
Oben