28
OpenVPN verbindet, routet aber normal weiter
Ich habe auf meinem debian Server OpenVPN eingerichtet. Als Client kommt die OpenVPN Connect APP für Android zum Einsatz.
Für die Einrichtung bin ich (VPN Anfänger) einer Anleitung gefolgt. Wenn ich in der APP die VPN Verbindung starte, wird in der Statuszeile das Schlüssel Symbol angezeigt; auf dem Server sehe ich in der /etc/openvpn/openvpn-status.log auch, dass der Client verbunden ist.
Was mich nun etwas verwirrt:
1. Der Client ist für andere Sites (z. B. http://www.utrace.de/) weiterhin mit seiner Original IP sichtbar, nicht wie von mir erwartet mit der des Servers.
2. Eine Traceroute APP zeigt keinen Unterschied, ob VPN verbunden ist oder nicht. Die Route ist jeweils die gleiche, die IP meines VPN-Servers taucht darin nicht auf.
Wo liegt mein Denkfehler, was habe ich falsch konfiguriert?
debian Server: OpenVPN server.conf
Android client: OpenVPN client.ovpn (statt "example.net" steht bei remote natürlich die echte Domain)
debian Server: iptables Regeln
Für die Einrichtung bin ich (VPN Anfänger) einer Anleitung gefolgt. Wenn ich in der APP die VPN Verbindung starte, wird in der Statuszeile das Schlüssel Symbol angezeigt; auf dem Server sehe ich in der /etc/openvpn/openvpn-status.log auch, dass der Client verbunden ist.
Was mich nun etwas verwirrt:
1. Der Client ist für andere Sites (z. B. http://www.utrace.de/) weiterhin mit seiner Original IP sichtbar, nicht wie von mir erwartet mit der des Servers.
2. Eine Traceroute APP zeigt keinen Unterschied, ob VPN verbunden ist oder nicht. Die Route ist jeweils die gleiche, die IP meines VPN-Servers taucht darin nicht auf.
Wo liegt mein Denkfehler, was habe ich falsch konfiguriert?
debian Server: OpenVPN server.conf
port 1194
;proto tcp
proto udp
;dev tap
dev tun
;dev-node MyTap
ca ca.crt
cert vpn-server.crt
key vpn-server.key # This file should be kept secret
dh dh4096.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 8.8.8.8"
;push "dhcp-option DNS 8.8.4.4"
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
;client-to-client
;duplicate-cn
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
comp-lzo
;max-clients 100
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
;log-append openvpn.log
verb 3
;mute 20Android client: OpenVPN client.ovpn (statt "example.net" steht bei remote natürlich die echte Domain)
client
;dev tap
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote vpn.example.net 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca ca.crt
cert android1.crt
key android1.key
ns-cert-type server
;tls-auth ta.key 1
;cipher AES-128-CBC
comp-lzo
verb 3
;mute 20debian Server: iptables Regeln
$iptables -A INPUT -i venet0:0 -m state --state NEW -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o venet0:0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $my_interface -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0:0 -j MASQUERADE
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 370021
Url: https://administrator.de/forum/openvpn-verbindet-routet-aber-normal-weiter-370021.html
Ausgedruckt am: 23.12.2024 um 18:12 Uhr
28 Kommentare
Neuester Kommentar
Hi,
du hast eine Verbindung durch das VPN von deinem Android Device zu dem Server hergestellt.
Was du nicht erstellt hast ist irgendein Routing zu andere Netzen bzw. zu 0.0.0.0 durch das VPN.
Das der Client für andere Sites mit seiner originalen IP sichtbar ist ist also richtig, aber vielleicht nicht erwünscht.
Wenn du allenTraffic durch das VPN routen willst fehlt die z.B. der Eintrag push "redirect-gateway xxxx"
siehe z.B. hier
CH
du hast eine Verbindung durch das VPN von deinem Android Device zu dem Server hergestellt.
Was du nicht erstellt hast ist irgendein Routing zu andere Netzen bzw. zu 0.0.0.0 durch das VPN.
Das der Client für andere Sites mit seiner originalen IP sichtbar ist ist also richtig, aber vielleicht nicht erwünscht.
Wenn du allenTraffic durch das VPN routen willst fehlt die z.B. der Eintrag push "redirect-gateway xxxx"
siehe z.B. hier
CH
Danke. Ich habe nun in der server.conf
eingetragen, nach dem Neustart des openvpn Services finde ich im Protokoll
… da sind bestimmt ein paar "undef" zu viel. ;) Wie bekomme ich die noch weg?
push "redirect-gateway def1 bypass-dhcp" eingetragen, nach dem Neustart des openvpn Services finde ich im Protokoll
[…]
Wed Apr 4 21:19:55 2018 us=428012 ROUTE: default_gateway=UNDEF
Wed Apr 4 21:19:55 2018 us=428470 TUN/TAP device tun0 opened
Wed Apr 4 21:19:55 2018 us=428496 TUN/TAP TX queue length set to 100
Wed Apr 4 21:19:55 2018 us=428514 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Apr 4 21:19:55 2018 us=428536 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Wed Apr 4 21:19:55 2018 us=444189 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Wed Apr 4 21:19:55 2018 us=445013 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Apr 4 21:19:55 2018 us=445503 Listening for incoming TCP connection on [undef]
Wed Apr 4 21:19:55 2018 us=445565 TCPv4_SERVER link local (bound): [undef]
Wed Apr 4 21:19:55 2018 us=445579 TCPv4_SERVER link remote: [undef]
Wed Apr 4 21:19:55 2018 us=445609 MULTI: multi_init called, r=256 v=256
Wed Apr 4 21:19:55 2018 us=445695 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Wed Apr 4 21:19:55 2018 us=445715 ifconfig_pool_read(), in='android1,10.8.0.4', TODO: IPv6
Wed Apr 4 21:19:55 2018 us=445745 succeeded -> ifconfig_pool_set()
Wed Apr 4 21:19:55 2018 us=445759 IFCONFIG POOL LIST
Wed Apr 4 21:19:55 2018 us=445771 android1,10.8.0.4
Wed Apr 4 21:19:55 2018 us=445803 MULTI: TCP INIT maxclients=1024 maxevents=1028
Wed Apr 4 21:19:55 2018 us=445847 Initialization Sequence Completed… da sind bestimmt ein paar "undef" zu viel. ;) Wie bekomme ich die noch weg?
Moin,
der TO braucht keine Routen konfigurieren.
Es fehlt nur das flag, dass Clients den gesamten Traffic durch den Tunnel schieben sollen. Dies Weisung muss durch den Server erfolgen.
Gruß
Spirit
der TO braucht keine Routen konfigurieren.
Es fehlt nur das flag, dass Clients den gesamten Traffic durch den Tunnel schieben sollen. Dies Weisung muss durch den Server erfolgen.
Gruß
Spirit
Richtig !
Vermutlich hat er die server.conf Datei falsch eingerichtet und dort mit "push route..." nur das lokale Gateway auf den VPN Client geroutet, dann ist logisch das dann nur der VPN Traffic für das remote lokale Netz in den Tunnel geht aber kein kompletter Redirect der allen Traffic in den Tunnel routet.
Das muss man in der server.conf natürlich entsprechend einrichten mit:
push "redirect-gateway def1"
Siehe auch:
https://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Dann klappt das auch sofort !
Wie Kollege Spirit-of-Eli oben schon zu Recht bemerkt fehlen sämtliche Routing Kommandos in der .conf Datei auf dem Server. Klar und logisch das es dann nicht funktionieren kann denn dann wird einzig nur die VPN Verbindung auf den Server selber gemacht und nix anderes.
Mit den HE Netzwerk Tools auf dem Smartphone und einem Traceroute hätte man das auch selber ganz ohne Thread hier gesehen:
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Für Debian ist es auch hier beschrieben:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
oder hier im Forum:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Vermutlich hat er die server.conf Datei falsch eingerichtet und dort mit "push route..." nur das lokale Gateway auf den VPN Client geroutet, dann ist logisch das dann nur der VPN Traffic für das remote lokale Netz in den Tunnel geht aber kein kompletter Redirect der allen Traffic in den Tunnel routet.
Das muss man in der server.conf natürlich entsprechend einrichten mit:
push "redirect-gateway def1"
Siehe auch:
https://openvpn.net/index.php/open-source/documentation/howto.html#redir ...
Dann klappt das auch sofort !
Wie Kollege Spirit-of-Eli oben schon zu Recht bemerkt fehlen sämtliche Routing Kommandos in der .conf Datei auf dem Server. Klar und logisch das es dann nicht funktionieren kann denn dann wird einzig nur die VPN Verbindung auf den Server selber gemacht und nix anderes.
Mit den HE Netzwerk Tools auf dem Smartphone und einem Traceroute hätte man das auch selber ganz ohne Thread hier gesehen:
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Für Debian ist es auch hier beschrieben:
https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ...
oder hier im Forum:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
push "redirect-gateway def1" habe ich eingetragen, dennoch funktioniert es immer noch nicht. Fehlen weitere Routing Infos, wie sollten diese aussehen?
Meine server.conf (nur die aktivien Einträge) sieht nun so aus:
Wenn ich den auf dem Client das VPN starte, steht in openvpn.log folgendes:
Auf dem Client funktioniert anschließend weder PING, noch DNS Auflösung, TRACEROUTE liefert demnach auch keine Ergebnisse…
Aus den verlinkten Tutorials werde ich auch nicht schlau. Ich sehe nicht, was ich vergessen / falsch konfiguriert habe. Mir ist auch unklar, waum in der letzten Protokoll Zeile ifconfig 10.8.0.6 10.8.0.5 steht, der Client sollte doch die 10.8.0.4 bekommen, nicht?
Meine server.conf (nur die aktivien Einträge) sieht nun so aus:
port 1194
proto udp
dev tun
ca ca.crt
cert vpn-server.crt
key vpn-server.key # This file should be kept secret
dh dh4096.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
cipher AES-128-CBC # AES
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 4Wenn ich den auf dem Client das VPN starte, steht in openvpn.log folgendes:
Thu Apr 5 10:15:36 2018 us=806382 79.199.192.55:53677 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 4096 bit RSA
Thu Apr 5 10:15:36 2018 us=806419 79.199.192.55:53677 [android1] Peer Connection Initiated with [AF_INET]79.199.192.55:53677
Thu Apr 5 10:15:36 2018 us=806460 android1/79.199.192.55:53677 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=1cca:7ab7:421:b7bf:e823:b7bf:8016:a2b8
Thu Apr 5 10:15:36 2018 us=806515 android1/79.199.192.55:53677 MULTI: Learn: 10.8.0.6 -> android1/79.199.192.55:53677
Thu Apr 5 10:15:36 2018 us=806529 android1/79.199.192.55:53677 MULTI: primary virtual IP for android1/79.199.192.55:53677: 10.8.0.6
Thu Apr 5 10:15:36 2018 us=822453 android1/79.199.192.55:53677 PUSH: Received control message: 'PUSH_REQUEST'
Thu Apr 5 10:15:36 2018 us=822481 android1/79.199.192.55:53677 send_push_reply(): safe_cap=960
Thu Apr 5 10:15:36 2018 us=822524 android1/79.199.192.55:53677 SENT CONTROL [android1]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1) Auf dem Client funktioniert anschließend weder PING, noch DNS Auflösung, TRACEROUTE liefert demnach auch keine Ergebnisse…
Aus den verlinkten Tutorials werde ich auch nicht schlau. Ich sehe nicht, was ich vergessen / falsch konfiguriert habe. Mir ist auch unklar, waum in der letzten Protokoll Zeile ifconfig 10.8.0.6 10.8.0.5 steht, der Client sollte doch die 10.8.0.4 bekommen, nicht?
Fehlen weitere Routing Infos, wie sollten diese aussehen?
Nein !Mehr ist nicht zu tun.
Du solltest niemals Google DNS 8.8.8.8 usw. als DNS Server konfigurieren. Das machen heutzutage nur noch Dummies oder blutige Laien. Jedermann weiss das Google Profile deines Surfverhaltens damit erstellt und über Dritte vermarktet. Musst du selber wissen was dir die Privatsphäre wert ist.
DHCP brauchst du in der server.conf gar nicht konfigurieren und auch kein DNS. Wenn du einen Redirect machst, und unbedingt DNS konfigurieren willst, dann n immst du deinen DNS Server vom Heimnetz oder dort wohin du den Redirect machst.
Der DNS ist in der Regel immer der heimische Router der als DNS Proxy agiert.
Lasse das also besser weg. Damit sind dann alle deine o.a. push dhcp Konfigs falsch.
Den OpenVPN Server hast du mit service openvpn restart neu gestartet nach Änderung der Konfig Datei ?
Mir ist auch unklar, waum in der letzten Protokoll Zeile ifconfig 10.8.0.6 10.8.0.5 steht
Eigentlich sollte er die 10.8.0.2 bekommen als erster Client wenn du einen 24er Prefix im internen OVPN Netz verwendest ?! (.1 = Server)Hängt aber auch davon ab WIE du die interne IP Distribution an die Clients konfiguriert hast. Mit dem ifconfig-pool-persist ipp.txt gibst du hier ja eine Verteilung vor. Entweder besser weglassen oder das darin korrigieren !
https://openvpn.net/archive/openvpn-users/2006-05/msg00316.html
Mit ifconfig-push 10.8.0.2 10.8.0.1 kannst du das in der client.conf beim Client auch erzwingen.
Generell solltest du alles überflüssige hier erstmal weglassen oder auskommentieren und mit den Defaults arbeiten.
Danke für den "Zaunpfahl", google DNS ist raus…
Ja, ich starte den openvpn Service nach jeder Änderung durch. Ich lösche in der APP das VPN Profil, bevor ich dort die Konfig ändere; zuletzt importiere ich das Profil neu. Bei jedem neuen Aufbau der VPN Verbindung ist also immer die jeweils aktuellste Konfig aktiv.
Ich habe die Konfiguration noch einmal geändert, so weit wie ich Deine Tipps (hoffentlich richtig) verstanden habe; die Datei ipp.txt habe ich komplett entsorgt. Falls da noch immer "überflüssiges" drin steht: nenne mir doch bitte die Zeilennummern, damit ich das auch mal rausnehmen kann; TIA.
egrep -v "^#|^$|^\;" server.conf
egrep -v "^#|^$|^\;" android1.ovpn
Dennoch das gleiche: nach Starten der VPN Verbindung wieder kein PING, kein DNS, kein TRACEROUTE auf dem Client… Im Protokoll auf dem server steht weiterhin "ifconfig 10.8.0.6 10.8.0.5":
In den APP Bewertungen wird von Verbindungs–Problemen im Zusammenhang mit Android 8 berichtet … bin ich etwa auch davon betroffen? (Server: debian 7 VM bei Strato; Client: honor 9 lite mit Android 8 / März Update)
Ja, ich starte den openvpn Service nach jeder Änderung durch. Ich lösche in der APP das VPN Profil, bevor ich dort die Konfig ändere; zuletzt importiere ich das Profil neu. Bei jedem neuen Aufbau der VPN Verbindung ist also immer die jeweils aktuellste Konfig aktiv.
Ich habe die Konfiguration noch einmal geändert, so weit wie ich Deine Tipps (hoffentlich richtig) verstanden habe; die Datei ipp.txt habe ich komplett entsorgt. Falls da noch immer "überflüssiges" drin steht: nenne mir doch bitte die Zeilennummern, damit ich das auch mal rausnehmen kann; TIA.
egrep -v "^#|^$|^\;" server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert vpn-server.crt
key vpn-server.key # This file should be kept secret
dh dh4096.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 120
cipher AES-128-CBC # AES
comp-lzo
status openvpn-status.log
log-append openvpn.log
verb 4egrep -v "^#|^$|^\;" android1.ovpn
client
dev tun
proto udp
remote vpn.example.net 1194 # hier steht statt example.net natürlich die richtige Domain
resolv-retry infinite
nobind
ifconfig-push 10.8.0.2 10.8.0.1
ca ca.crt
cert android1.crt
key android1.key
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 3Dennoch das gleiche: nach Starten der VPN Verbindung wieder kein PING, kein DNS, kein TRACEROUTE auf dem Client… Im Protokoll auf dem server steht weiterhin "ifconfig 10.8.0.6 10.8.0.5":
Thu Apr 5 12:52:39 2018 us=11941 79.199.192.55:37928 [android1] Peer Connection Initiated with [AF_INET]79.199.192.55:37928
Thu Apr 5 12:52:39 2018 us=11981 android1/79.199.192.55:37928 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=1caa:72b7:24f2:c1bf:8f5:c1bf:b862:93b7
Thu Apr 5 12:52:39 2018 us=12029 android1/79.199.192.55:37928 MULTI: Learn: 10.8.0.6 -> android1/79.199.192.55:37928
Thu Apr 5 12:52:39 2018 us=12041 android1/79.199.192.55:37928 MULTI: primary virtual IP for android1/79.199.192.55:37928: 10.8.0.6
Thu Apr 5 12:52:39 2018 us=13880 android1/79.199.192.55:37928 PUSH: Received control message: 'PUSH_REQUEST'
Thu Apr 5 12:52:39 2018 us=13903 android1/79.199.192.55:37928 send_push_reply(): safe_cap=960
Thu Apr 5 12:52:39 2018 us=13942 android1/79.199.192.55:37928 SENT CONTROL [android1]: 'PUSH_REPLY,redirect-gateway def1,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1) In den APP Bewertungen wird von Verbindungs–Problemen im Zusammenhang mit Android 8 berichtet … bin ich etwa auch davon betroffen? (Server: debian 7 VM bei Strato; Client: honor 9 lite mit Android 8 / März Update)
Lass das "ifconfig-push 10.8.0.2 10.8.0.1" auf dem Client mal komplett weg, dann vergibt der Server das dynamisch.
Damit hättest du dann eine simple Standard Konfig.
Damit muss es gehen !
Wenn du nicht pingen kannst WAS pingst du denn da als Ziel ??
Erstmal ist es wichtig das du den Server selber pingst !!! Also die 10.8.0.1
Das muss IMMER klappen !
Dann mal das lokale LAN Interface des Servers
Dann mal sowas wie 8.8.8.8
Nimm immer die nackte IP, denn das umgeht erstmal ggf. vorhandene DNS Probleme.
Wie gesagt die HE Tools für Android und iOS sind sehr hilfreich dafür:
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server und dann ist es auch klar, das der gesamte Rest nicht funktioniert !
Damit hättest du dann eine simple Standard Konfig.
Damit muss es gehen !
Wenn du nicht pingen kannst WAS pingst du denn da als Ziel ??
Erstmal ist es wichtig das du den Server selber pingst !!! Also die 10.8.0.1
Das muss IMMER klappen !
Dann mal das lokale LAN Interface des Servers
Dann mal sowas wie 8.8.8.8
Nimm immer die nackte IP, denn das umgeht erstmal ggf. vorhandene DNS Probleme.
Wie gesagt die HE Tools für Android und iOS sind sehr hilfreich dafür:
https://play.google.com/store/apps/details?id=net.he.networktools&hl ...
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server und dann ist es auch klar, das der gesamte Rest nicht funktioniert !
2Wenn du nicht pingen kannst WAS pingst du denn da als Ziel ??
Erstmal ist es wichtig das du den Server selber pingst !!! Also die 10.8.0.1
Das muss IMMER klappen !
Dann mal das lokale LAN Interface des Servers
Dann mal sowas wie 8.8.8.8
Nimm immer die nackte IP, denn das umgeht erstmal ggf. vorhandene DNS Probleme.
Erstmal ist es wichtig das du den Server selber pingst !!! Also die 10.8.0.1
Das muss IMMER klappen !
Dann mal das lokale LAN Interface des Servers
Dann mal sowas wie 8.8.8.8
Nimm immer die nackte IP, denn das umgeht erstmal ggf. vorhandene DNS Probleme.
Kurz zu Ergänzung, falls du einen Windows Rechner mit aktiver Firewall versuchst zu pingen wird dies ohne zusätzliche Regel zum erlauben des VPN Netzes nicht funktionieren. Windows blockt alle Subnetz, die es nicht kennt.
Zitat von @aqui:
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server (…)
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server (…)
m(
Ich habe die iptables Regeln für openvpn nun mal an den Anfang des FW–Scriptes gestellt, damit klappt zumindest schon einmal
a) ping auf 10.8.0.1
b) Abruf von E—Mail auf dem Server (der selbe, auf dem openvpn läuft)
c) Abruf von Websites auf dem Server (—""—)
ifconfig-push 10.8.0.2 10.8.0.1 habe ich komplett raus genommen, bekomme weiterhin den "ifconfig 10.8.0.6 10.8.0.5" Logfile–Eintrag beim Aufbau der VPN Verbindung.
Der Client bekommt immer wieder die 10.8.0.6 zugewiesen (mit lt. Network Analyzer App einer Subnetz Maske von 255.255.255.252). Ich habe nach der …0.6 gesucht, sie steht in keiner der Konfig–Dateien, nicht einmal auskommentiert.
PING auf z. B. 8.8.8.8 kommt nicht zurück (es wird keine Laufzeit angezeigt), immerhin zeigt die APP (Network Analyzer) zu IP auch den Hostnamen google-public-dns-a.google.com an. Ping auf google.com zeigt die aufgelöste IP 172.217.16.206 an, allerdings auch hier keine Laufzeiten. (Also scheint DNS nun auch zu funktionieren.)
Versuche ich in Firefox eine Website zu laden, die nicht auf meinem Server liegt (z. B. heise.de), bekomme ich "Fehler: Netzwerk–Zeitüberschreitung".
Ausgabe von route auf der Server–Konsole:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
loopback * 255.0.0.0 U 0 0 0 lo
default * 0.0.0.0 U 0 0 0 venet0
Bitte nicht alles zitieren !
So kann man doch niemals lesen und verstehen was du antwortest
Irgendwo her muss er das ja bekommen ! Der OVPN Server vergibt ohne Konfig immer fortlaufend...
Kannst ja spaßeshalber das interne Netz mal umbiegen auf 172.31.31.0 /24 und mal checken was er dann macht ?!
Interessant wäre die Routing Tabelle auf dem Client !!
Dort schlägt vermutlich der Gateway Redirect fehl, deshalb "kennt" er nur das VPN Netz 10.8.0.0 /24, routet also nur Pakete mit diesem Netz in den Tunnel.
Alles andere rennt dann außerhalb des Tunnels...vermutlich ?!
Um das sicher sagen zu können braucht man die Routing Tabelle des Clients bei aktivem VPN Client !
So kann man doch niemals lesen und verstehen was du antwortest
wo kommt da jetzt die 10.8.0.2 her?
OpenVPN macht ein Point to Point Netzwerk intern mit Hostrouten !bekomme weiterhin den "ifconfig 10.8.0.6 10.8.0.5" Logfile–Eintrag beim Aufbau der VPN Verbindung.
Da stimmt irgendwas nicht !Irgendwo her muss er das ja bekommen ! Der OVPN Server vergibt ohne Konfig immer fortlaufend...
Kannst ja spaßeshalber das interne Netz mal umbiegen auf 172.31.31.0 /24 und mal checken was er dann macht ?!
Interessant wäre die Routing Tabelle auf dem Client !!
Dort schlägt vermutlich der Gateway Redirect fehl, deshalb "kennt" er nur das VPN Netz 10.8.0.0 /24, routet also nur Pakete mit diesem Netz in den Tunnel.
Alles andere rennt dann außerhalb des Tunnels...vermutlich ?!
Um das sicher sagen zu können braucht man die Routing Tabelle des Clients bei aktivem VPN Client !
Ich versuche auf dem Android Client nur PING auf IPs, die ich auch mit meinem ubuntu Desktop anpingen kann.
Zitat von @Herr-N:
Ich versuche auf dem Android Client nur PING auf IPs, die ich auch mit meinem ubuntu Desktop anpingen kann.
Ich versuche auf dem Android Client nur PING auf IPs, die ich auch mit meinem ubuntu Desktop anpingen kann.
Das heißt ja nicht viel, befindet sich dein Ubuntu System in dem selben Subnetz wie die IPs, die du versuchst zu pingen?
War das jetzt versteckte Ironie? (Die Frage meine ich absolut ernst.) Ich probier's jetzt mal mit ein paar mehr Zitaten …
bekomme weiterhin den "ifconfig 10.8.0.6 10.8.0.5" Logfile–Eintrag beim Aufbau der VPN Verbindung.
Irgendwo her muss er das ja bekommen ! Der OVPN Server vergibt ohne Konfig immer fortlaufend...Kannst ja spaßeshalber das interne Netz mal umbiegen auf 172.31.31.0 /24 und mal checken was er dann macht ?!
Dann bekommt der Android Client zuverlässig die IP 172.31.31.6 zugewiesen. Im Logfile steht dann "ifconfig 172.31.31.6 172.31.31.5", ansonsten ist das Verhalten praktisch identisch: alles lokale auf dem Server ist erreichbar; fremde Server im Netz jedoch nicht.
Interessant wäre die Routing Tabelle auf dem Client !!
Dort schlägt vermutlich der Gateway Redirect fehl, deshalb "kennt" er nur das VPN Netz 10.8.0.0 /24, routet also nur Pakete mit diesem Netz in den Tunnel.
Alles andere rennt dann außerhalb des Tunnels...vermutlich ?!
Um das sicher sagen zu können braucht man die Routing Tabelle des Clients bei aktivem VPN Client !
Dort schlägt vermutlich der Gateway Redirect fehl, deshalb "kennt" er nur das VPN Netz 10.8.0.0 /24, routet also nur Pakete mit diesem Netz in den Tunnel.
Alles andere rennt dann außerhalb des Tunnels...vermutlich ?!
Um das sicher sagen zu können braucht man die Routing Tabelle des Clients bei aktivem VPN Client !
Ich habe mir mal die Termux Konsole App installiert. Wenn ich dort den Befehl route eingebe, bemomme ich folgenden Output:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.12.0 * 255.255.255.0 U 0 0 0 wlan0
10.8.0.4 * 255.255.255.252 U 0 0 0 tun0In der App Network Analyzer sehe ich unter dem Menü "Information" bei den Punkten Default Gateway IP und DNS Server IP bei inaktivem VPN jeweils die IP meines lokalen Routers; wenn ich VPN aktiviere steht dort N/A!
Ich habe mal die Client–Konfig auf eine VM (VirtualBox) mit ubuntu 17.04 übernommen. Wenn ich dort openvpn (von der Konsole aus) starte, verhält es sich praktisch genau so wie der Android Client.
Hier ein Screenshot, IPs meines LAN habe ich rot, die des openVPN Servers blau gestrichen:
Ein traceroute sieht so aus:
Hier ein Screenshot, IPs meines LAN habe ich rot, die des openVPN Servers blau gestrichen:
Ein traceroute sieht so aus:
Zitat von @Spirit-of-Eli:
Das heißt ja nicht viel, befindet sich dein Ubuntu System in dem selben Subnetz wie die IPs, die du versuchst zu pingen?
Das heißt ja nicht viel, befindet sich dein Ubuntu System in dem selben Subnetz wie die IPs, die du versuchst zu pingen?
Der ubuntu Rechner und das Android Smartphone sind im selben LAN.
Der Ping geht an öffentliche Server wie z. B. google.com — also nicht an IP im selben Subnetz, wenn ich Deine Frage nun richtig verstehe.
Zitat von @aqui:
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server
Wenn das Pingen der OVPN Server IP schon scheitert, dann hast du ein Firewall Problem auf dem Server
Ich habe mal zum Test hier im LAN (auf meinem ubuntu Rechner) eine VM mit der gleichen Distro wie der Strato Server (debian 7) installiert. Dort habe ich OpenVPN mit der gleichen Konfiguration installiert.
Wenn ich den (Android) VPN Client mit dem VM–VPN verbinde, wird ihm auch dann die 10.8.0.6 zugewiesen. Aber: ich kann Hosts jenseits des VM–VPN Servers erreichen; also z. B. PING auf öffentliche Server (8.8.8.8 etc) funktioniert, TRACEROUTE sieht auch "normal" aus: als erster Hop erscheind die 10.8.0.1, dann die IP meines Routers, dann der Provider … und letztendlich der Ziel–Host.
Das bestätigt also den Verdacht, dass ich auf dem Strato Server ein Firewall–Problem habe. Darauf hin habe ich dessen iptables–Script testweise so weit reduziert, dass nur noch das nötigste und eben die Regeln fürs VPN drin sind: dennoch funktioniert das Routing über VPN "ins Internet" nicht, Traceroute geht immer nur bis zur 10.8.0.1.
Kann es sein, dass Strato diese Art der VPN Nutzung verhindert? Oder habe ich einen Fehler in den iptables Regeln fürs VPN?
my_interface=venet0:0
iptables -A INPUT -i $my_interface -m state --state NEW -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o $my_interface -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $my_interface -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o $my_interface -j MASQUERADEVielen Dank, das war der entscheidende Hinweis!
Nachdem das VPN mit der anderen VM reibungslos geklappt hat, habe ich nun die Fehlerquelle identifizieren können:
Auf dem Strato Server war eine "default policy" iptables -P FORWARD DROP eingetragen. Ändere ich diese in …ACCEPT klappt der Internet–Zugriff übers VPN einwandfrei. Ich hatte zwar gedacht, dass die der "default policy" nachfolgenden Regeln fürs VPN greifen müssten, dem war aber offensichtlich nicht so.
Nun frage ich mich allerdings, ob ich durch iptables -P FORWARD ACCEPT möglicherweise eine Sicherheitslücke aufgemacht habe. (Ja, Netzwerk ist nicht wirklich so mein Ding.) Aber das ist im Zweifelsfall ein anderes Thema.
Also noch einmal vielen Dank für Deine (/Eure) Unterstützung und Geduld, … schönes Wochenende!
War das jetzt versteckte Ironie? (Die Frage meine ich absolut ernst.)
Nein, denn du hast über die Zitatfunktion hier den gesamten Text zitiert (beige eingefärbt) was extrem nervig ist beim Lesen.Der ubuntu Rechner und das Android Smartphone sind im selben LAN.
- Der Ubuntu Rechner hat einen Default Route auf den Internet Router und kann diesen und z.B. die 8.8.8.8 pingen ?
- Hast du beachtet das du auf deinem Internet Router eine statische Route für das interne OVPN Netzwerk eintragen musst ? Klar, denn sonst kann der Internet Router Pakete mit der Quelladresse 10.8.0.0 /24 nicht rückrouten ! Dort muss also sowas stehen wie: Ziel: 10.8.0.0, Maske: 255.255.255.0, Gateway: <ip_adresse_ubuntu>
dass ich auf dem Strato Server ein Firewall–Problem habe
Wie vermutet !Auf dem Starto MUSST dü übrigens NAT (Masquerading) aus dem internen VPN Netz machen da sonst die 10er IP ins Internet gehen würde und der Provider die filtert.
Im lokalen Test Setup müsste man das nicht unbedingt...ist aber hilfreicher, damit man 2 identisches Setups hat.
Nun frage ich mich allerdings, ob ich durch iptables -P FORWARD ACCEPT möglicherweise eine Sicherheitslücke aufgemacht habe.
Das kannst du ganz einfach mit dem ct Netzwerkcheck ausprobieren:https://www.heise.de/security/dienste/Netzwerkcheck-2114.html
Ansonsten lässt du mal einen nmap Scan auf den Server los, was auch die weltweiten Angreifer alle Minute machen:
Netzwerk Management Server mit Raspberry Pi
Wenn du fail2ban (hoffentlich) auf dem Server installiert hast wirst du das auch selber wissen !
Zitat von @aqui:
Nein, denn du hast über die Zitatfunktion hier den gesamten Text zitiert (beige eingefärbt) was extrem nervig ist beim Lesen.
Nein, denn du hast über die Zitatfunktion hier den gesamten Text zitiert (beige eingefärbt) was extrem nervig ist beim Lesen.
Komisch, ich sehe das bei mir nicht. Und im Allgemeinen achte ich auch sehr darauf, keine Fullquotes einzubauen.
Egal....wenn der Server jetzt zum Fliegen kommt ist doch alles paletti ! 
1
Ja, bin gerade dabei, Client–Konfigs für die anderen User anzulegen.
Die anderen Sachen schaue ich mir später an. fail2ban habe ich auch auf dem Server laufen, derzeit allerdings nur jails für ssh und Mailserver aktiv.
Die anderen Sachen schaue ich mir später an. fail2ban habe ich auch auf dem Server laufen, derzeit allerdings nur jails für ssh und Mailserver aktiv.
Wenn du dir dann mal das Log ansiehst weisst du wovon wir reden
Lesenswert dazu:
https://www.heise.de/ct/ausgabe/2015-4-Dienste-sicher-ins-Netz-bringen-2 ...
Lesenswert dazu:
https://www.heise.de/ct/ausgabe/2015-4-Dienste-sicher-ins-Netz-bringen-2 ...
Welches Log meinst Du? Ich schaue regelmäßig in die üblichen Logfiles und habe meine Kisten bislang immer ganz gut gesichert gehabt. Zumindest ist es mir nicht bekannt, dass es in den letzten 15 Jahren mal unbefugte Zugriffe gab. Da ich mich auf der Netzwerk Ebene –zugegeben– nicht besonders gut auskenne, bin ich mit Änderungen an der FW etc. immer eher vorsichtig / skeptisch … never change a running system.
Den heise Netzwerkcheck kann ich für meinen Server leider nicht durchführen.
https://www.ssllabs.com/ssltest/analyze.html vergibt meinem Server ein A, bei https://observatory.mozilla.org/ gibt's wegen CSP Abzügen "nur" ein B+.
nmap auf https://pentest-tools.com/ zeigt auch nichts unerwartetes:
Schönes WE!
Den heise Netzwerkcheck kann ich für meinen Server leider nicht durchführen.
https://www.ssllabs.com/ssltest/analyze.html vergibt meinem Server ein A, bei https://observatory.mozilla.org/ gibt's wegen CSP Abzügen "nur" ein B+.
nmap auf https://pentest-tools.com/ zeigt auch nichts unerwartetes:
Schönes WE!
Welche s Log meinst Du?
Das fail2ban Log !Dort kann man ja die Angriffe im Sekundentakt mitverfolgen. Ist auf Internet Routern übrigens identisch.
15 Jahren mal unbefugte Zugriffe gab.
Spricht für dich und deine Absicherung ....zeigt auch nichts unerwartetes:
Das sieht doch dann gut aus und du kannst beruhigt in ein sonniges Wochenende Zitat von @aqui:
Dort kann man ja die Angriffe im Sekundentakt mitverfolgen. Ist auf Internet Routern übrigens identisch.
Welche s Log meinst Du?
Das fail2ban Log !Dort kann man ja die Angriffe im Sekundentakt mitverfolgen. Ist auf Internet Routern übrigens identisch.
Ach so, … ja, auch im fail2ban.log schaue ich regelmäßig nach; schon wg der Kandidaten, die nach einer permanenten DROP Regel bitten.
Was Router anbetrifft bin ich nach fli4l (auf 486er) und openwrt inzwischen bei OPNsense angekommen und damit sehr zufrieden.
Spricht für dich und deine Absicherung
Danke fürs Kompliment. Ich bin zwar nicht immer der schnellste, dafür noch immer lernfähig. Und ich habe ein paar Prinzipien, die sich bewährt haben, wie z. B. nicht-trivial-ratbare Nutzerkennungen. So gibt es z. B. ein fail2ban jail, das alle IPs für ein paar Stunden sperrt, von denen aus ein Anmelde–Versuch am IMAP mit einer E–Mail–Adresse als Nutzerkennung erfolgt.
Hashes meiner Passwörter^H Passphrasen finden sich auch nicht in der "Pwned Passwords" (https://haveibeenpwned.com/Passwords) Datenbank … inzwischen haben sogar meine Nutzer verstanden, dass "Passwort" keines ist. https://xkcd.com/936/
....zeigt auch nichts unerwartetes:
Das sieht doch dann gut aus und du kannst beruhigt in ein sonniges Wochenende Danke, dito.
inzwischen bei OPNsense angekommen und damit sehr zufrieden.
Ist auch nicht falsch aber die pfSense_Variante bietet derzeit etwas mehr Stabilität und vor allem Features.nicht-trivial-ratbare Nutzerkennungen.
Bei im Internet erreichbaren Servern sollte ,man immer wenn irgend möglich gar nicht mehr mit Passwörtern arbeiten sondern mit SSH nur noch Schlüssel verwenden:https://www.heise.de/ct/hotline/FAQ-SSH-Secure-Shell-3939853.html
OPNsense läuft bei mir absolut stabil und bietet mir auch genug Features.
Für SSH verwende ich schon lange Schlüssel. Für E–Mail wird's bis auf weiteres Benutzerkennung / PWD (über TLS) bleiben. Da finde ich es dann sehr praktisch, triviale Nutzerkennungen per fail3ban regeln zu lassen – das hält das Logfile übersichtlich.
Für SSH verwende ich schon lange Schlüssel. Für E–Mail wird's bis auf weiteres Benutzerkennung / PWD (über TLS) bleiben. Da finde ich es dann sehr praktisch, triviale Nutzerkennungen per fail3ban regeln zu lassen – das hält das Logfile übersichtlich.
