ComputerBase Menü
Aktuelles

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

Die letzte Zeile ist lediglich eine simple NAT-Regel. Die Geräte hinter dem PI kennen das VPN-Subnetz gar nicht und wissen unter Umständen mit einem Paket aus diesem Netz nichts anzufangen. Das hat also erstmal nix mit deinem Problem zu tun. Ansonsten sieht das eigentlich ganz ok aus.

Wenn beim OpenVPN-Server kein Verbindungsversuch von außen zu sehen ist, kann es grundsätzlich an 3 Stellen hängen:

1. Die interne Firewall bzw. die iptables blockieren die eingehenden Pakete (sieht für mich ok aus)
2. Die Portweiterleitung im Router klappt nicht (sieht auch ok aus)
3. Die Firewall im Fremd-LAN blockiert die ausgehende Verbindung (unbekannt)

Ich kann dir jetzt viele Tips geben wie du dein Netzwerk checkst (zB mit Netzwerksniffer), aber Trial&Error ist ziemlich kompliziert, wenn du nicht @home testen kannst. Evtl. mit nem Kumpel sprechen, der dir seinen PC via TeamViewer zur Verfügung stellt. Dann kannst du von dort aus den Außenzugriff testen. Sonst bist du in 4 Wochen immer noch dabei..
 
Zuletzt bearbeitet:
Raijin schrieb:
Ich kann dir jetzt viele Tips geben wie du dein Netzwerk checkst (zB mit Netzwerksniffer), aber Trial&Error ist ziemlich kompliziert, wenn du nicht @home testen kannst. Evtl. mit nem Kumpel sprechen, der dir seinen PC via TeamViewer zur Verfügung stellt. Dann kannst du von dort aus den Außenzugriff testen. Sonst bist du in 4 Wochen immer noch dabei..
Zum Vergrößern anklicken....

Ja, ich weiß dass das ganze nicht wirklich ideal ist. Aktuell wüsste ich auch niemanden, den ich dazu einspannen könnte.
Aber bislang sieht das ganz ja ganz gut aus. Das externe Netz ein wenig "abzuklopfen" hatte ich mir schon vorgenommen. Und allein dauert es wohl in der Tat eine ganze Weile, wenn es doch nicht so gedacht funktionieren sollte.

EDIT:
Erste Zwischenbilanz:
Der Datenverkehr läuft über einen Proxy... d.h. ich muss die beiden Configs wohl nun auf TCP statt UDP umstellen :pcangry:
 
Zuletzt bearbeitet:
Eventuell reicht auch ein klärendes Gespräch mit dem örtlichen IT-Administrator.

VPN via TCP ist suboptimal und sollte nach Möglichkeit vermieden werden. Wenn UDP aus welchen Gründen auch immer nicht möglich ist, hast du in dem Szenario leider keine andere Wahl.
 
Mit den Admins könnte es schwierig werden. Denn die Infrastruktur steht weitestgehend (eher alte Rechner mit, bei den Nutzerrechten recht verriegeltem Vista oder komplett offenes XP... Installationen so denn möglich überleben keinen Neustart. ). Und Admins sind nur bei Havarien, aber erst recht nicht für die Leute die sich dort weiterbilden erreichbar.

Also wird mir wohl nichts anderes übrigbleiben als den ganzen Spaß über TCP zu machen.
 
Kleiner Tip: Du kannst auch mehrere VPN-Server parallel laufen lassen. Will heißen: Erstelle mehrere server.conf zB mit TCP 1194, TCP 443, TCP 8080, etc. und starte sie. So kannst du mehrere Konfigurationen auf einmal testen, ohne ständig hin- und herfahren zu müssen.

zB so:

server1.conf -> proto tcp -> port 1194
server2.conf -> proto tcp -> port 443
server3.conf -> proto tcp -> port 8080
server4.conf -> proto udp -> port 1194
server5.conf -> proto udp -> port 443
server6.conf -> proto udp -> port 8080

Router: Portweiterleitung 6x 1:1, also tcp1194@pi:1194, tcp443@pi:443, etc.
 
Danke für den Hinweis mit den parallel laufenden Servern, dies so einzurichten hat sich ausgezahlt.

Also Zwischenbilanz:
Erstes kleines Erfolgserlebnis - die Verbindung konnte aufgebaut werden.
Aber die Nutzung des Browsers funktioniert trotzdem nicht. Es wird keine Seite geladen.
Letzteres scheint aber wohl eine reine Client-Sache oder ein Ding der richtigen Einstellung auf dem XP Rechner zu sein.
Und das ganze unabhängig davon, ob ich im Client bei den Proxy-Einstellungen die erste oder zweite Option wähle:
VPN-Proxy.png


Übrigens von den getesteten Konfigs hat nur TCP über Port 443 funktioniert.

Hier das Log des Windows-Clients. Die ausführlicheren (dem höheren Verbose-Level geschuldeten) dem folgenden Log vorangestellten Details bei der Vereinbarung der Client-Config habe ich mal weggelassen (Ich hoffe das ich alle privaten IPs und Daten beim "schwärzen" erwischt habe :rolleyes:):
Code: 
Wed Sep 17 08:38:02 2014 us=62000 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Wed Sep 17 08:38:02 2014 us=62000 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Sep 17 08:38:02 2014 us=156000 LZO compression initialized
Wed Sep 17 08:38:02 2014 us=156000 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Sep 17 08:38:02 2014 us=156000 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Sep 17 08:38:02 2014 us=312000 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Sep 17 08:38:02 2014 us=312000 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Sep 17 08:38:02 2014 us=312000 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Sep 17 08:38:02 2014 us=312000 Local Options hash (VER=V4): '69109d17'
Wed Sep 17 08:38:02 2014 us=312000 Expected Remote Options hash (VER=V4): 'c0103fa8'
Wed Sep 17 08:38:02 2014 us=312000 Attempting to establish TCP connection with XXX.XXX.XXX.XXX:443
Wed Sep 17 08:38:02 2014 us=453000 TCP connection established with XXX.XXX.XXX.XXX:443
Wed Sep 17 08:38:02 2014 us=453000 TCPv4_CLIENT link local: [undef]
Wed Sep 17 08:38:02 2014 us=453000 TCPv4_CLIENT link remote: XXX.XXX.XXX.XXX:443
Wed Sep 17 08:38:02 2014 us=625000 TLS: Initial packet from XXX.XXX.XXX.XXX:443, sid=30285937 bbf9feae
Wed Sep 17 08:38:06 2014 us=250000 VERIFY OK: depth=1, /C=DE/ST=XX/L=XXXXX/O=XXXXX/OU=XXXXX/CN=XXXXX.selfhost.eu/name=changeme/emailAddress=XXXXXXX@XXXXXXX.com
Wed Sep 17 08:38:06 2014 us=250000 VERIFY OK: nsCertType=SERVER
Wed Sep 17 08:38:06 2014 us=250000 VERIFY OK: depth=0, /C=DE/ST=XX/L=XXXXX/O=XXXXX/OU=XXXXX/CN=server/name=changeme/emailAddress=XXXXXXX@XXXXXXX.com
Wed Sep 17 08:38:14 2014 us=312000 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Sep 17 08:38:14 2014 us=312000 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 17 08:38:14 2014 us=312000 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Sep 17 08:38:14 2014 us=312000 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 17 08:38:14 2014 us=312000 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Wed Sep 17 08:38:14 2014 us=312000 [server] Peer Connection Initiated with XXX.XXX.XXX.XXX:443
Wed Sep 17 08:38:16 2014 us=500000 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Sep 17 08:38:17 2014 us=140000 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 85.214.20.141,dhcp-option DNS 8.8.8.8,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Wed Sep 17 08:38:17 2014 us=140000 OPTIONS IMPORT: timers and/or timeouts modified
Wed Sep 17 08:38:17 2014 us=140000 OPTIONS IMPORT: --ifconfig/up options modified
Wed Sep 17 08:38:17 2014 us=140000 OPTIONS IMPORT: route options modified
Wed Sep 17 08:38:17 2014 us=140000 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Sep 17 08:38:17 2014 us=140000 ROUTE default_gateway=192.168.21.254
Wed Sep 17 08:38:17 2014 us=156000 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{EB729D67-0E2A-44A0-9D39-811911EFEADE}.tap
Wed Sep 17 08:38:17 2014 us=156000 TAP-Win32 Driver Version 9.9 
Wed Sep 17 08:38:17 2014 us=156000 TAP-Win32 MTU=1500
Wed Sep 17 08:38:17 2014 us=156000 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {EB729D67-0E2A-44A0-9D39-811911EFEADE} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Wed Sep 17 08:38:17 2014 us=156000 DHCP option string: 060855d6 148d0808 0808
Wed Sep 17 08:38:17 2014 us=156000 Successful ARP Flush on interface [65540] {EB729D67-0E2A-44A0-9D39-811911EFEADE}
Wed Sep 17 08:38:22 2014 us=250000 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Wed Sep 17 08:38:22 2014 us=250000 Route: Waiting for TUN/TAP interface to come up...
Wed Sep 17 08:38:27 2014 us=843000 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Wed Sep 17 08:38:27 2014 us=843000 C:\WINDOWS\system32\route.exe ADD XXX.XXX.XXX.XXX MASK 255.255.255.255 192.168.21.254
Wed Sep 17 08:38:27 2014 us=843000 Route addition via IPAPI succeeded [adaptive]
Wed Sep 17 08:38:27 2014 us=843000 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.5
Wed Sep 17 08:38:27 2014 us=843000 Route addition via IPAPI succeeded [adaptive]
Wed Sep 17 08:38:27 2014 us=843000 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.5
Wed Sep 17 08:38:27 2014 us=843000 Route addition via IPAPI succeeded [adaptive]
Wed Sep 17 08:38:27 2014 us=843000 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5
Wed Sep 17 08:38:27 2014 us=843000 Route addition via IPAPI succeeded [adaptive]
Wed Sep 17 08:38:27 2014 us=843000 Initialization Sequence Completed
 
Zuletzt bearbeitet:
Wunderbar ;)

Bezüglich des Browsers mach mal folgende Tests am Client:

Eingabeaufforderung
-> ping google.de (<-- geht ein normaler ping auf google.de?)
-> ping 8.8.8.8 (<-- wenn nicht, geht's dann direkt auf die IP?)
-> nslookup google.de (<-- was sagt der Standard-DNS?)
-> nslookup google.de 8.8.8.8 (<-- was sagt der google-dns?)
-> tracert 8.8.8.8 (<-- welchen Weg nehmen die Daten? 1. Station sollte 10.8.0.1 sein)

Wenn eins davon fehlschlägt, dann kann man im Browser auch keine Seiten aufrufen und muss sich um die DNS-Einstellungen prüfen. Sollte sogar der Ping auf eine IP fehlschlagen oder aber die Routenverfolgung (tracert) nimmt den falschen Weg, dann ist vermutlich das Standard Gateway falsch.
 
Raijin schrieb:
Wenn eins davon fehlschlägt, dann kann man im Browser auch keine Seiten aufrufen und muss sich um die DNS-Einstellungen prüfen. Sollte sogar der Ping auf eine IP fehlschlagen oder aber die Routenverfolgung (tracert) nimmt den falschen Weg, dann ist vermutlich das Standard Gateway falsch.
Zum Vergrößern anklicken....

Leider schlägt alles davon fehl :(. Und zwar mit den üblichen Fehlermeldungen "Servername nicht gefunden", "Zeitüberschreitung" usw..
Daher wird wohl tatsächlich das Gateway falsch sein.

Übrigens schlägt einzig nslookup generell fehl, auch ohne VPN-Verbindung, also im regulären Netz:
Code: 
nslookup google.de
254.21.168.192.in-addr.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
*** Der Servername für die Adresse 192.168.21.254 konnte nicht gefunden werden:
No information
*** Die Standardserver sind nicht verfügbar.
Server:  UnKnown
Address:  192.168.21.254

Nicht autorisierte Antwort:
Name:    google.de
Addresses:  173.194.112.215, 173.194.112.216, 173.194.112.223, 173.194.112.207

... und das gleich mit dem OpenVPN:
Code: 
nslookup google.de
DNS request timed out.
    timeout was 2 seconds.
*** Der Servername für die Adresse 85.214.20.141 konnte nicht gefunden werden:
Timed out
DNS request timed out.
    timeout was 2 seconds.
*** Der Servername für die Adresse 8.8.8.8 konnte nicht gefunden werden:
Timed out
254.21.168.192.in-addr.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
*** Der Servername für die Adresse 192.168.21.254 konnte nicht gefunden werden:
No information
*** Die Standardserver sind nicht verfügbar.
Server:  UnKnown
Address:  85.214.20.141

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown
 
Zuletzt bearbeitet:
Der erste nslookup ist vollkommen in Ordnung. Die ersten "Fehler" besagen nur, dass für den DNS selbst (192.168.21.254) im LAN kein Name gefunden werden konnte. Bei mir daheim steht da beispielsweise "speedport.ip", weil das der lokale DNS ist. Die eigentliche Antwort steht in den Zeilen 16-18, nämlich die IP-Adressen von google.de

Beim zweiten nslookup ist das anders. Hier werden nacheinander mehrere DNS abgefragt. Allerdings gab es keine Antwort auf den DNS-Request.

Mach mal 'tracert 8.8.8.8' einmal mit, einmal ohne VPN und poste das Ergebnis hier. Ebenso die Routing-Tabelle ('route print') einmal mit, einmal ohne.
 
OK erst einmal vielen Dank für die ganze Hilfe über die letzten paar Tage... denn...

Nun funktioniert es tadellos. Das Problem, dass es gestern nicht klappte, hatte seine Ursache wohl ausschließlich darin, dass ich mehrere Server laufen ließ und sich diese offenbar gegenseitig im Weg waren.

Gestern mal alle Server-Configs bis auf jene mit TCP Port 443 entfernt... und schon rennt das Netz ganz wunderbar und ungeblockt.

:schluck:
 
:daumen:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

B
  • Gelöst
Frage zu OpenVPN Server auf OPNsense
Antworten
11
Aufrufe
814
balombi
B
M
OpenVPN - Tp-Link - Probleme
Antworten
4
Aufrufe
744
musikverstärker
M
J
Tp Link MR600 VPN mit wireguard
Antworten
11
Aufrufe
969
norKoeri
N
B
Raspberry Pi - OpenVpn Server mit DDNS von NO-IP Aufsetzen
Antworten
9
Aufrufe
2.145
BestJust16
B
E
PI-Hole wird ignoriert
2
Antworten
35
Aufrufe
1.420
EK38
E
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 165 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz