OpenVPN Server auf RaspberryPi von "außen" erreichen Konfiguration/ DynamicDNS/Ports

kaydon · 22. Januar 2014

Hallo,

zuerst einmal: im Forum habe ich gesucht und kein passendes Thema gefunden, per Suchmaschinen im www auch nur unspezifisch.

Deswegen möchte ich hier meine Fragen stellen und hoffe auf hilfreiche Antworten

Also, gestern habe ich meinen RaspberryPi bekommen und eingerichtet. D.h. OS Raspbian + OpenVPN per shell installiert und konfiguriert (zum ersten Mal, kenne mich damit nicht gut aus).
Die Key-Dateien, die ich im OpenVPN-Server konfiguriert habe, hab ich per ftp-client auf z.B. meinen Laptop übertragen. Anschließend in den config Ordner des OpenVPN Client auf dem Notebook (Win 8.1) kopiert und die OpenVPN client Gui ausgeführt. VPN Tunnel funktioniert! Anmerkung im OpenVPN-Server ist die lokale IP des Raspberry eingetragen (hängt per Lan-Kabel direkt am Telekom Speedport 723v router).
Im Router ist die IP des Raspberry fest eingestellt (DHCP ist aus). Diese IP ist auch im OpenVPN-Server während der Konfiguration eingetragen, also 192.168.2.104.
Gleichzeitig habe ich nen selfhost dynamicDNS registriert und somit eine Domain (meinname.selfhost.eu) erhalten.
Im Speedport 723v menü ist der DDNS aktiviert und "meinname.selfhost.eu" sowie "benutzer" und "passwort" eingetragen.
Die aktuelle ip vom router wird im selfhost.de portal angezeigt, wenn ich mich dort einlogge.
Im 723v router hab ich ne portregel definiert, mit dem namen Raspberry und dort "weiterleitung" auf die Raspberry IP/Hostname (PC192-168-2-104) und im Feld TCP-Ports den Port 22 freigeschaltet (per remoteverbindung innerhalb des netzwerks kann ich per IP 192.168.2.104 und per Port 22 zugreifen auf den raspberry) und den port 1194, weil er im OpenVPN-Server in eine KEY-Datei für die client eingetragen ist (war so und per VPNclient bekomm ich ja auch ne connection).
Wenn ich über nen Proxy server (damit kein Loop entsteht, da ich ja innerhalb des Netzwerks bin hier beim Testen) die domain: meinname.selfhost.eu eingebe oder "meinname.selfhost.eu:22" oder "meinname.selfhost.eu:1194" passiert nichts, keine Verbindung möglich.
Hab auch versucht die Domain "meinname.selfhost.eu" in der OpenVPN-Server konfiguration für 192.168.2.104 zu ersetzen. Dann connected der VPN-Client aber auch gar nicht mehr.

Die Frage ist also, wie stelle ich nun den VPN-Tunnel von außerhalb her (oder testweise über nen proxy von innerhalb) unter Verwendung meiner DDNS Domain?

Sorry für den langen Text, abr so sieht man, was ich schon alles konfiguriert hab und was fehlen könnte.

Grüße - Kaydon

HominiLupus · 22. Januar 2014

Was für einen Proxy hast du genutzt? Webproxies werden nicht funktionieren. Webbrowser als Client natürlich auch nicht.

Es sollte mindestens z.B. Tor sein und z.B. telnet.exe oder PuTTY

kaydon · 22. Januar 2014

webproxy hatte ich getestet. Per putty habe ich die konfiguration durchgeführt. Wenn ich in putty die Domain "meinname.selfhost.eu" eingebe und den freigeschalteten port, komm ich auch nicht durch, nur bei Eingabe von 192.168.2.104 und port 22

wenn ich in der Win 8.1 CMD "ping meinname.selfhost.eu" eintippe, bekomm ich einen erfolgreichen statusbericht!

DeusoftheWired · 22. Januar 2014

Von innerhalb deines LANs wird es nicht funktionieren, Stichwort WAN Loopback. Teste das ganze von außen, also an einem anderen Anschluß als deinem eigenen. Oder mit einem Mobiltelephon (das natürlich nicht WLAN sondern seine richtige Mobilfunknetzverbindung nutzt) und einem vertrauenswürdigen Client.

Weiter muß der Raspi auch eingehende Verbindungen, die nicht aus dem LAN stammen, auf den VPN-Ports akzeptieren. Wie die Standardeinstellungen der iptables von Raspbian sind, weiß ich leider nicht. Bei RaspBMC mußte ich sie jedenfalls manuell anpassen. Anzeigen lassen kannst du sie dir so:

Code:

sudo iptables -L

kaydon · 22. Januar 2014

Ich habe soeben zum ersten Mal mit Putty über meine Domain bei selfhost auf meinen raspberry von außen zugreifen können. Allerdings lief der VPN-Tunnel nicht, ich arbeite dran, damit vll .andere, die ähnliche Probleme haben hier auch eine Lösung finden!

Ergänzung (22. Januar 2014)

So: Das Problem war der Speedport. Obwohl die Ports freigeschaltet waren, kam nichts durch. Nachdem ich nun mehrere Ports freigeschaltet hab, ist aus welchen Gründen auch immer nun einer durchlässig, so dass der Tunnel aufgebaut werden kann! Speedports scheinen Probleme zu haben. Achja, voraus ging eine Odyssee an Resets des Routers und verschiedene Konfigurationen!

close!

Belphegor666 · 10. September 2014

Sorry, dass ich den Thread aus dem Keller hole. Aber ich stehe aktuell vor exakt dem gleichen Problem.

Also OpenVPN Server auf dem RaspberryPi... DynDNS über selfhost.de.. usw.
Alles ist eingerichtet und sollte auch funktionieren, aber ich bekomme einfach den verdammten OpenVPN Port 1194 auf dem Speedport W723 V nicht auf, obwohl dieser für UDP (und TCP) im Web-Interface freigeschaltet wurde. Ich habe alles durchprobiert, auch mehrere Ports auf einmal zu öffnen.
Bei Tests mit Online-Portscannern wird mir 1194 immer als geschlossen angezeigt.

Ich fände es daher mal interessant, welche Ports der Threadersteller denn nun genau bei sich geöffnet hat, damit es klappt.

Raijin · 10. September 2014

Den Port von außen kannst du frei wählen.

Eine Portweiterleitung besteht aus 3 Komponenten:

Port von außen
weiterleiten an IP x
auf Port y

Beispiel:

443 -> 192.168.1.17 -> 1194

Wenn es bei dir von außen nicht geht, kannst du denn vom LAN aus auf den OpenVPN-Server verbinden (ohne DDNS, direkt auf die LAN-IP des PI)? Sollte das schon fehlschlagen, kann die Portweiterleitung auch nix tun.

Belphegor666 · 10. September 2014

Raijin schrieb:
Wenn es bei dir von außen nicht geht, kannst du denn vom LAN aus auf den OpenVPN-Server verbinden (ohne DDNS, direkt auf die LAN-IP des PI)? Sollte das schon fehlschlagen, kann die Portweiterleitung auch nix tun.

Danke für den Hinweis. Die komplette Konfiguration von OpenVPN auf dem Raspberry hatte ich in der Tat noch nicht getestet. Dies scheint aber soweit zu funktionieren.
Getestet habe ich es auf dem Mac mit "Tunnelblick". Wie vorgeschlagen habe ich in der .ovpn config (zusätzlich zu den Schlüsseln) die dynDNS zur lokalen IP des Raspberry geändert. "Tunnelblick" ist anstandslos gestartet und hat auch sofort die Verbindung aufgebaut. Gleich mal getestet per Zugriff auf http://www.speedtest.net/ und mittels ausgeführtem 'top' auf dem Raspberry auch gesehen, dass OpenVPN sich recht viel Rechenzeit genehmigt - soweit also alles im grünen Bereich. Einzige kleine Fehlermeldung war die naheliegende Feststellung des VPN-Clients, dass sich die "scheinbare" öffentliche IP nach dem Verbinden nicht geändert hat.

Über den eingerichteten DynDNS klappte es jedoch weiterhin nicht, egal was ich auch immer im Router bei "Port-Weiterleitung" und/oder "Port-Umleitung" einstelle. Kein Wunder, da ich die passenden Ports beim Speedport W723 V einfach nicht offen bekomme.

Raijin · 10. September 2014

"Öffnen" muss man die Ports im Router eigentlich auch nicht, sie werden einfach nur weitergeleitet. Sofern also die Portweiterleitung eingerichtet ist, sollte es auch funktionieren, ABER:

Es ist in der Regel nicht möglich, aus einem LAN heraus ins Internet und dann wieder zurück ins LAN zu gehen. Will heißen, wenn du im (W)LAN sitzt und dich mit deinem VPN über selfhost verbinden willst und die Verbindung am Router rausgeht und quasi sofort wieder reinkommt, klappt das nicht.
Um das auszuschließen, bietet es sich an, am Handy einen Hotspot aufzumachen und den Laptop via WLAN an diesen Hotspot zu klemmen. Dann geht die VPN-Verbindung über das mobile Netz und kommt als "externe Verbindung" beim Router an und wird (hoffentlich) an den PI weitergeleitet.

Belphegor666 · 10. September 2014

Raijin schrieb:
Zitat entfernt.

Ob das ganze aber mit einem anderen als dem eigenen Netz funktioniert, kann ich aktuell aber nicht testen, da ich leider kein Smartphone mein eigen nenne. Von außerhalb des eigenen Netzes kann ich es daher erst morgen testen.

Sehe ich es aber richtig, dass die Sichtbarkeit der (vermeintlich offenen) Ports von außen (also über die schon genannten Online-Portscanner in dem Sinne gar nicht relevant ist? Ich ging davon aus dass zum Funktionieren des OpenVPN der dafür relevante Port 1194 als "offen" angezeigt werden muss.

Wie man merkt habe ich von derartigen Dingen leider überhaupt keine Peilung…

Meine aktuelle Port-Forwarding Einstellung sieht übrigens so aus:

Testweise hatte ich mal alle UDP-Ports weitergeleitet. Da der Speedport W723 V wohl 2 Ports reserviert hat (5050 & 7547) sah das ganze so aus:
1-5059,5061-7546,7548-65535

Per Port-Scanner werden die Ports aber immer noch als geschlossen angezeigt

Raijin · 10. September 2014

Jein.. Eine Portweiterleitung ist für sich erstmal KEIN offener Port. Ein Port ist erst dann offen, wenn eine Anwendung auf diesem Port auf eingehende Verbindungen wartet. Bei einer Portweiterleitung und einem Portscan von außen, wird der Port also erst dann als offen angezeigt, wenn der Router den Port an ein Gerät im LAN weiterleitet UND dieses Gerät auf diesen Port auch reagiert. Will heißen: Wenn zB der OpenVPN-Server nicht läuft, wird der Port auch geschlossen bleiben, egal ob weitergeleitet oder nicht. Läuft der Server und die Weiterleitung ist aktiv, aber der Port ist immer noch zu bzw. es ist keine Verbindung möglich, dann kann es mehre Gründe haben. Zum einen kann dir die Firewall des PI einen Strich durch die Rechnung machen (zB indem nur Anfragen aus dem LAN, also mit Quell-IP im Heim-Subnetz akzeptiert werden) oder zum anderen blockiert die Firewall im fremden LAN den Verbindungsaufbau.

Fremdes LAN: Bist du zB in der Firma, kann es sein, dass die Firewall nur Verbindungen auf bestimmte Ports zulässt (zB Port 80 zum Surfen), aber den Rest blockiert. Dadurch wird verhindert, dass zB jemand privat Skype nutzt oder irgendwelche Download-Tools, etc. Dann wäre auch dein VPN-Tunnel nicht möglch (aus dem genannten Firmen-LAN). Um das zu umgehen, kann man gängige Standardports für den VPN-Tunnel verwenden, die in der Regel nicht blockiert werden (80, 443, etc)

Belphegor666 · 11. September 2014

Raijin schrieb:
Zum einen kann dir die Firewall des PI einen Strich durch die Rechnung machen (zB indem nur Anfragen aus dem LAN, also mit Quell-IP im Heim-Subnetz akzeptiert werden) oder zum anderen blockiert die Firewall im fremden LAN den Verbindungsaufbau.

Zur erstgenannten Problematik auf dem Pi. Dies wurde in der Anleitung zur Einrichtung von OpenVPN, welcher ich gefolgt bin bereits berücksichtigt, indem man via iptables die Firewall des PI öffnete.

Raijin schrieb:
Fremdes LAN: Bist du zB in der Firma, kann es sein, dass die Firewall nur Verbindungen auf bestimmte Ports zulässt (zB Port 80 zum Surfen), aber den Rest blockiert. Dadurch wird verhindert, dass zB jemand privat Skype nutzt oder irgendwelche Download-Tools, etc. Dann wäre auch dein VPN-Tunnel nicht möglch (aus dem genannten Firmen-LAN). Um das zu umgehen, kann man gängige Standardports für den VPN-Tunnel verwenden, die in der Regel nicht blockiert werden (80, 443, etc)

Und zum zweiten… das kann ich mir in der Tat gut vorstellen, aber bislang testen konnte ich es nicht, da ich aktuell noch nicht einmal den OpenVPN Client zum laufen bekam, weil ich dort erst auf einen Rechner ausweichen muss, für welchen man keine Admin Rechte für den OpenVPN Client braucht.
… ich habe auch schon angedacht auf dem Pi statt auf OpenVPN lieber gleich einen Proxy Server zur Nutzung im Browser einzusetzen.

Allgemein türmen sich jedoch noch mehr Probleme auf, da ich laut einigen Forenbeträgen bei der Telekom erfahren habe, dass wohl speziell der Speedport W723 V offenbar in der Tat größere Probleme beim Port Forwarding hat. Und da es leider nur ein Mietrouter ist, kann ich jenen noch nicht einmal mit geeigneterer Software modifizieren.

Raijin · 12. September 2014

Proxy und VPN sind ja prinzipiell zwei Paar Schuhe. Ich weiß ja nicht genau was du damit vorhast, aber wenn du zB von außen auf dein heimisches NAS zugreifen willst, würde ich dir dringendst zu einem VPN raten.
So oder so wird die Problematik der Testphase aber bleiben: Wenn du nicht "von außen" testen kannst, kann man nur spekulieren warum was wie wo nicht funktioniert. Deswegen bietet es sich an, das via Smartphone-Hotspot zu probieren, was bei dir natürlich schwierig wird

Wenn's zeitlich passt, kann ich mich heute abend oder am Wochenende testweise mit deinem VPN verbinden - keine Angst, ich nehme ein Dummy-Zertifikat und das wird sofort abgelehnt (=keine Verbindung). Aber immerhin kann man so sehen ob Server und Client miteinander reden oder nicht. Zumindest wird man so die Portweiterleitung grundsätzlich testen können.

Belphegor666 · 12. September 2014

OK ich konnte das VPN (und die diversen Ports) nun doch endlich mal testen.
Und es hat "natürlich" nicht funktioniert.

VPN getestet mit dem OpenVPN Portable Client (natürlich mit der eigenen Konfig und den Schlüsseln)... hier der relevante Teil des Logs des Client (bereinigt um meine IP

):

Fri Sep 12 08:49:11 2014 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Sep 12 08:49:11 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Sep 12 08:49:11 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Sep 12 08:49:11 2014 LZO compression initialized
Fri Sep 12 08:49:11 2014 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 08:49:11 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Sep 12 08:49:19 2014 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 12 08:49:19 2014 Local Options hash (VER=V4): '41690919'
Fri Sep 12 08:49:19 2014 Expected Remote Options hash (VER=V4): '530fdded'
Fri Sep 12 08:49:19 2014 UDPv4 link local: [undef]
Fri Sep 12 08:49:19 2014 UDPv4 link remote: xxx.xxx.xxx.xxx:1194
Fri Sep 12 08:50:19 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 12 08:50:19 2014 TLS Error: TLS handshake failed
Fri Sep 12 08:50:19 2014 TCP/UDP: Closing socket
Fri Sep 12 08:50:19 2014 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 12 08:50:19 2014 Restart pause, 2 second(s)

Danach habe ich auch gleich mal per NMap die relevanten Ports abgeklopft (ebenfalls bereinigt um meine IP):

Raijin · 12. September 2014

Von wo hast du es denn nu getestet? Nachbar? Büro? Hotspot? Handy? Dem Log nach zu urteilen antwortet der Server in der Tat nicht, sonst stünde da anstelle von "TLS Error: ..." sowas wie "TLS: Initial packet from aaa.bbb.ccc.ddd:eeee"

Um eine potentielle Blockade der Firewall im Fremdnetz auszuschließen, kannst du die Portweiterleitung auf 53, 80, 443 oder zB 8080 legen. Also von außen zB 80 auf den PI an Port 1194 leiten.

Belphegor666 · 12. September 2014

Getestet habe ich es von innerhalb einer Weiterbildungseinrichtung. Was Übrigens auch der Sinn des ganzen sein soll. Deren Filtereinstellungen sind recht rigide eingestellt, so das man noch nicht einmal auf linkedin.com kommt. Und sich täglich nach noch funktionierenden (und vor allem schnellen) Proxies umzuschauen ist mir auf Dauer zu mühselig (und bei manchem Datenverkehr auch nicht immer vertrauenswürdig). Zur Not würde es daher auch ein eigener Proxy tun, was in dem Sinne auch sinnvoll wäre, da einige der in der Einrichtung verwendeten Rechner zwar uralt sind, aber für OpenVPN die Admin-Rechte fehlen… jedoch wäre mit OpenVPN sicherlich auch mehr möglich, damit ich so meine Daten auch gleich irgendwo im eigenen Netzwerk ablegen kann.

Nur mal zur Info habe ich den Verbose Level des Logs mal etwas ausführlicher eingestellt. Sonderlich viel neue Infos sind aber dadurch trotzdem nicht zu erwarten.

Code:

Fri Sep 12 12:23:39 2014 us=546000 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Sep 12 12:23:39 2014 us=546000 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Sep 12 12:23:39 2014 us=546000 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Sep 12 12:23:39 2014 us=640000 LZO compression initialized
Fri Sep 12 12:23:39 2014 us=640000 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 12:23:39 2014 us=656000 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Sep 12 12:23:39 2014 us=734000 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 12 12:23:39 2014 us=734000 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Fri Sep 12 12:23:39 2014 us=734000 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Fri Sep 12 12:23:39 2014 us=734000 Local Options hash (VER=V4): '41690919'
Fri Sep 12 12:23:39 2014 us=734000 Expected Remote Options hash (VER=V4): '530fdded'
Fri Sep 12 12:23:39 2014 us=734000 UDPv4 link local: [undef]
Fri Sep 12 12:23:39 2014 us=734000 UDPv4 link remote: xxx.xxx.xxx.xxx:1194
Fri Sep 12 12:23:39 2014 us=734000 UDPv4 WRITE [14] to xxx.xxx.xxx.xxx:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Sep 12 12:23:39 2014 us=734000 UDPv4 READ [0] from [undef]: DATA UNDEF len=-1
Fri Sep 12 12:23:42 2014 us=15000 UDPv4 WRITE [14] to xxx.xxx.xxx.xxx:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Sep 12 12:23:46 2014 us=562000 UDPv4 WRITE [14] to xxx.xxx.xxx.xxx:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Sep 12 12:23:54 2014 us=171000 UDPv4 WRITE [14] to xxx.xxx.xxx.xxx:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Sep 12 12:24:10 2014 us=218000 UDPv4 WRITE [14] to xxx.xxx.xxx.xxx:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Sep 12 12:24:40 2014 us=125000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 12 12:24:40 2014 us=125000 TLS Error: TLS handshake failed
Fri Sep 12 12:24:40 2014 us=125000 TCP/UDP: Closing socket
Fri Sep 12 12:24:40 2014 us=125000 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 12 12:24:40 2014 us=125000 Restart pause, 2 second(s)

Da jetzt Wochenende ist, kann ich die Vorschläge leider erst am Dienstag ausprobieren.
Aber nur mal zum Verständnis… in dem Sinne sollte dann wohl meine Portweiterleitung im Router so aussehen:

Und meine .ovpn Konfig des Client angepasst an den gewählten Port:

Code:

dev tun
client
proto udp
remote meineAdresse.selfhost.eu 8080
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 6

Aber wenn ich das richtig verstanden habe, bleibt der Port in der .conf des Servers auf dem Raspberry unangetastet, da der Router dafür sorgt das die Anfragen des Clients an Port 8080 im internen Netz zu 1194 umgeleitet werden.
Also ab konkreten Beispiel:

Code:

dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
# WICHTIG: Hier die Datei entsprechend der Schlüssellänge (Schritt 3) eintragen
dh /etc/openvpn/easy-rsa/keys/dh1024.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
script-security 2
keepalive 10 120
client-to-client
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 85.214.20.141"
push "dhcp-option DNS 8.8.8.8"
log-append /var/log/openvpn
comp-lzo

Könnte man dann nicht auch gleich in beiden, der Client- & Serverkonfig einfach einen alternativen Port zu 1194 also wie im Beispiel eben 8080 (ohne Weiterleitung im Router) eintragen. Also in der server.config des Pi Port 8080 und in der .ovpn des Client ebenfalls diesen Port, so dass der ganze OpenVPN Verkehr über 8080 läuft?
Genau das hatte ich nämlich schon vor ein paar Tagen zum Test mit den internen IPs schon mit Port 443 probiert... mit dem Ergebnis, dass der Server auf dem Pi nicht laufen wollte.

Raijin · 12. September 2014

Den Server selbst würde ich immer auf dem Standardport belassen, egal von welcher Anwendung wir sprechen - sei es ftp, ssh, vpn, etc.. Prinzipiell kann man natürlich die server.conf auch anpassen und direkt 443, 8080 oder was auch immer als Port einstellen. Aber: Wenn du irgendwann mal den "richtigen" Dienst auf diesem Port laufen lassen willst (443 wäre https, 8080 ist ein alternativer http port), dann gibt es sofort Probleme, weil der Port am Server schon belegt ist. Deswegen belasse ich die Serverdienste immer auf Standard und ändere gegebenenfalls die Umleitung im Router, wenn ich zB den VPN-Tunnel von außen auf einem anderen Port "brauche" - beispielsweise wegen der örtlichen Firewall.

Es sollte also so sein:

client.conf -> remote server.adresse 8080
Portweiterleitung -> 8080 auf pi.ip 1194
server.conf -> port 1194

Wenn du den Server auf udp laufen lässt, brauchst du im Router auch nur udp weiterleiten. Die Umleitung von tcp ist in dem Falle nicht notwendig (andersherum ebenfalls).

Was sagt denn das Log auf dem Server, während des Verbindungsversuchs? Rattert der auch los, wenn der Client das Handshake versucht? Ansonsten sieht die Konfiguration ok aus, wobei ich beim client immer "ns-cert-type server" verwenden würde, um Man-In-The-Middle-Attacken weitestgehend auszuschließen.

Belphegor666 · 12. September 2014

OK hier mal das OpenVPN Server-Log des Pi von heute:

Code:

Fri Sep 12 01:24:14 2014 event_wait : Interrupted system call (code=4)
Fri Sep 12 01:24:14 2014 TCP/UDP: Closing socket
Fri Sep 12 01:24:14 2014 /sbin/route del -net 10.8.0.0 netmask 255.255.255.0
SIOCDELRT: Operation not permitted
Fri Sep 12 01:24:14 2014 ERROR: Linux route delete command failed: external program exited with error status: 7
Fri Sep 12 01:24:14 2014 Closing TUN/TAP interface
Fri Sep 12 01:24:14 2014 /sbin/ifconfig tun0 0.0.0.0
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
Fri Sep 12 01:24:14 2014 Linux ip addr del failed: external program exited with error status: 255
Fri Sep 12 01:24:14 2014 SIGTERM[hard,] received, process exiting
Fri Sep 12 01:24:36 2014 OpenVPN 2.2.1 arm-linux-gnueabihf [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Oct 12 2013
Fri Sep 12 01:24:36 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Sep 12 01:24:36 2014 Diffie-Hellman initialized with 1024 bit key
Fri Sep 12 01:24:36 2014 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 12 01:24:36 2014 Socket Buffers: R=[163840->131072] S=[163840->131072]
Fri Sep 12 01:24:36 2014 ROUTE default_gateway=192.168.2.1
Fri Sep 12 01:24:36 2014 TUN/TAP device tun0 opened
Fri Sep 12 01:24:36 2014 TUN/TAP TX queue length set to 100
Fri Sep 12 01:24:36 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Sep 12 01:24:36 2014 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Fri Sep 12 01:24:36 2014 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Fri Sep 12 01:24:36 2014 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 12 01:24:36 2014 GID set to nogroup
Fri Sep 12 01:24:36 2014 UID set to nobody
Fri Sep 12 01:24:36 2014 UDPv4 link local (bound): [undef]
Fri Sep 12 01:24:36 2014 UDPv4 link remote: [undef]
Fri Sep 12 01:24:36 2014 MULTI: multi_init called, r=256 v=256
Fri Sep 12 01:24:36 2014 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Fri Sep 12 01:24:36 2014 Initialization Sequence Completed

Die diversen Fehlermeldungen stören mich schon ein wenig… aber bei dem Test über die interne IP rennt er ohne Probleme.
Wobei mir aber gerade auffällt, dass erstens die Uhrzeit im Log nicht stimmt und zweitens dies lediglich den Start des Servers anzeigt. Die etwaigen Verbindungsversuche die ich heute von außen versuchte sind nicht mit vermerkt - daher dürfte wohl zu keiner Zeit ein Kontakt zum Server von außen bestanden haben.

Die aber inzwischen gemachten Einstellungen zur Port-Umleitung werde ich aber wohl leider erst am Dienstag von außen testen können.

Raijin · 15. September 2014

Die Fehlermeldungen sollten eigentlich nicht sein. Ungeachtet dessen sieht man aber auch keinerlei eingehende Verbindungen. Das heißt, die Weiterleitung scheint nicht zu klappen.

Belphegor666 · 15. September 2014

Wie schon gesagt, von außen testen kann ich es erst morgen wieder.

Aber ich habe eine leise Ahnung wo die Fehlermeldungen im Log herrühren. Und zwar nach der open verlinkten Anleitung, nach welcher ich OpenVPN auf dem Pi eingerichtet habe, läuft auch ein Startscript "rpivpn" in /etc/init.d/ mit, welches offenbar für die "Weiterleitung" (Zitat laut jener Seite) und ich schätze auch das öffnen der Firewall zuständig ist:

Code:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          rpivpn
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: VPN initialisation script
### END INIT INFO

echo 'echo "1"  > /proc/sys/net/ipv4/ip_forward' | sudo -s
sudo iptables -A INPUT -i tun+ -j ACCEPT
sudo iptables -A FORWARD -i tun+ -j ACCEPT
sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -t nat -F POSTROUTING
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ich persönlich verdächtige die letzte Zeile, bzw. die IP-Angabe dafür verantwortlich zu sein. Ich hoffe, dass jene Fehler nicht ebenfalls die Kommunikation von Außen beeinträchtigen könnten. Denn allein intern gestartet und betrieben funktioniert der Server ohne Probleme.

OpenVPN Server auf RaspberryPi von "außen" erreichen Konfiguration/ DynamicDNS/Ports

Cadet 2nd Year

Banned

Cadet 2nd Year

Fleet Admiral

Cadet 2nd Year

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Fleet Admiral

Cadet 1st Year

Ähnliche Themen