OpenVPN Verbindung ins Heimnetzwerk

  • Hallo zusammen,


    ich bin momentan dran mir einen VPN Server auf einem vServer einzurichten, um von unterwegs mit Handy/Laptop auf mein Heimnetzwerk zugreifen zu können.

    Der OpenVPN Server ist auf dem Netcup vServer installiert. Innerhalb des Heimnetzwerkes läuft ein Raspberry Pi als Client, der erfolgreich eine Verbindung aufbaut (Ping in beide Richtungen funktioniert). Auf dem Handy ist ebenfalls OpenVPN als Client installiert. Verbinde ich nun auch das Handy mit dem VPN Server kann ich nun über den Browser auf die Fritzbox zugreifen und verwalten. Eine SSH Verbindung vom Handy zum Raspberry Pi klappt auch.

    Was jedoch nicht funktioniert ist der Zugriff auf meine Netzwerkfestplatte, die über einen Netgear Router bereitgestellt wird. Der Router lässt sich ebenfalls über den Browser verwalten.

    Ich verstehe jetzt nicht warum alle Verbindungen scheinbar funktionieren, ich aber kein Zugriff auf die Festplatte bekomme.


    Bei der Einrichtung habe ich mich an folgende Anleitung gehalten:

    https://crycode.de/openvpn-zug…zwerk-hinter-einem-client


    Wäre für jede Hilfe sehr dankbar, da ich mich auch nicht so sehr in der Materie auskenne.

  • Also Heimnetz ist: 192.168.1.x

    Fritzbox: 192.168.1.1

    Netgear Router: 192.168.1.2 (über LAN, nicht WAN an die Fritzbox angeschlossen)

    Raspberry Pi VPN Client: 192.168.1.3

    VPN Netz: 10.8.0.X

    Server: 10.8.0.1

    Raspberry Pi: 10.8.0.3


    Firewall Einstellungen hab ich bei dem Netgear (r7800) nur unter WAN gefunden und trotzdem alles dort ausgestellt.

    UDP Port 1194 in der Fritzbox für 192.168.1.3 ist freigegeben.


    Vielleicht ist es noch wichtig, dass ich keine öffentliche IPv4 mehr vom Internet Provider bekomme. Deswegen auch die Auslagerung auf einen vServer, da mein Mobilnetz kein IPv6 hat.


    Die Server Config:

    Für Rasperry Pi auf dem Server hinterlegt /etc/openvpn/ccd/

    Code
    1. # Feste IP für den Client (Client-IP Subnet)
    2. ifconfig-push 10.8.0.3 255.255.255.0
    3. # Internes Routing zum Heimnetz über diesen Client
    4. iroute 192.168.1.0 255.255.255.0

    Raspberry Pi Client Config:

    Ansonsten wurde auf dem Raspberry Pi noch folgendes ausgeführt:

    Code
    1. sudo sysctl -w net/ipv4/ip_forward=1
    2. sudo iptables -t nat -F POSTROUTING
    3. sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
  • Du brauchst in der Fritz den Port für VPN nicht freizugeben, da die Verbindung ja Outbound aufgebaut wird und der Rest geht dann über den Tunnel. Da der Zugriff per VPN auf deine Fritz und den Netgear Router funktioniert, scheint das Routing schonmal zu funktionieren.

    Wie ist die Platte ins Netzwerk integriert? USB am Netgear Router? Gleiche IP wie der Router? Der Zugriff aus 192.168.1.x auf die Platte funktioniert?

  • Alles klar, gut zu wissen. Ja genau externe Festplatte ist über USB am Netgear Router angeschlossen und wird über \\readyshare oder 192.168.1.2 aufgerufen, was im Heimnetz auch funktioniert.

  • Kannst du mal die routen auf dem Raspberry Pi prüfen? In der Server-Config legst du folgendes fest:


    Quote
    1. # Route zum Heimnetz allen Clients mitteilen
    2. push "route 192.168.1.0 255.255.255.0"


    Diese Route könnt mit der Heimnetz-Route auf dem Raspberry kollidieren (je nachdem, welche Distance gesetzt wird).


    Desweiteren würde ich im nächsten Schritt per tcpdump die Datenpakete vom Tunnel kommend auf das Netzwerkinterface in Richtung IP des Netgear Routers und TCP-Port 445 prüfen. Entsprechend natürlich auch die Antworten.

  • Ich vermute es liegt einfach an dem System von Netgear.

    Laut https://kb.netgear.com/30278/H…a-NETGEAR-router-remotely bekommst du den direkten Share Zugriff nur über "Network Neighborhood", ich vermute das bedeutet: Aus dem lokalen Subnetz (192.168.1.x). Anfragen aus anderen Netzen, wie z. B. deinem VPN Subnetz werden hingegen abgewiesen. Alternativ wird weiter unten auf der genannten Seite geschildert, dass du den im Router integrierten VPN Dienst nutzen kannst, allerdings wird das wohl ein Server sein, den du mit deiner Provider IP ja nicht von außen erreichen kannst.


    Hier gibts auch Probleme:

    https://community.netgear.com/…hare-from-vpn/td-p/474055

    https://community.netgear.com/…re-through-VPN/m-p/451829


    Ich weiß nicht ob das möglich ist, aber evtl. kannst du deinen VPN-Clients Adressen aus dem 192.168.1.x er Subnet zuweisen, z. B. 192.168.1.1-100 für lokale Clients (zugewiesen durch die Fritz) und 192.168.101-200 für deine VPN Clients. Ich vermute aber, dass das so nicht möglich ist, wegen 2 Gateways im gleichen Subnet. Aber vielleicht mit einer Bridge.


    Alternativ und was auf jeden Fall geht: USB HDD an deinen Raspi, dort Samba installieren und entsprechend die Freigabe konfigurieren. Dann hast du was Zugriffskontrolle angeht alles selbst in der Hand ;)

  • route -n auf dem Raspberry gibt folgendes aus:

    Code
    1. Destination Gateway Genmask Flags Metric Ref Use Iface
    2. 0.0.0.0 10.8.0.1 0.0.0.0 UG 0 0 0 tun0
    3. 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
    4. 192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
    5. net.cup.ip.123 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0

    tcpdump sagt mir noch nichts. Weiß jetzt nicht wie ich das umsetzen müsste, um das zu prüfen. Muss mich dann wohl erst einmal damit beschäftigen.

  • Danke für den Hinweis. Es scheint tatsächlich an dem Netgear Router zu liegen. OpenVPN geht auf dem Router momentan nur als Server, nicht als Client.

    Es hängt noch ein zusätzlicher Raspberry Pi zur Haussteuerung im Heimnetz, der eine Samba Freigabe besitzt. Auf die habe ich Zugriff, jedoch auch nur sehr langsam, sodass beispielsweise ein 3mb Bild nicht geladen wird, bevor es dann schließlich abbricht. Das kann doch auch nicht normal sein (trotz kleiner 16000 Leitung).

  • Das klingt nach einem MTU Problem. Ich würde testweise den Tunnel mal mit MTU 1400 und MSS 1300 laufen lassen. Der Overhead eines OpenVPN Paketes sollte bei ca 70 bytes pro Paket liegen. Dann könntest du dich mit MSS an 1330 rantasten. Angaben ohne Gewähr und aus dem Kopf, in der Regel testet man die maximale MTU-Größe zwischen den Anschlüssen mit ping und den entsprechenden Paketgrößen aus. Dann den Overhead (kann auch weniger als 70bytes sein) vom MTU-Wert abziehen und den MSS-Wert setzen.



    Code
    1. tun-mtu 1400
    2. mssfix 1300




    Hintergrund: http://doc-tcpip.org/Tcp-ip/mtu.mss.html

  • Was ich mich Fragen (ich denkemal du hast auf allen Clients die FB als Default Router gesetzt): Wo setzt du die Route ins VPN? Wenn du z.B. bei einem lokalen Rechner die 10.8.0.0/24 erreichen willst? Irgendwie muss du deinen Clients (oder der FB) beibringen, dass der PI der Router ins VPN ist.

  • Wenn der Hinweis mit dem Abweisen von anderen Subnetzen korrekt ist, wäre meines Erachtens ein Destination NAT auf dem Raspberry die einfachste Lösung..

    Ich meinte natürlich ein Source NAT. Sorry..

    Das macht der Raspberry ja auch bereits, wenn ich das richtig sehe:


    sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE

    Wenn dann ein Datenpaket aus 10.8.0.0/24 ankommt, wird es vom Raspberry mit der eigenen IP maskiert. Das sollte soweit passen.

  • Ich bin absoluter Linux Neuling kommer aber aus der IT Ecke (MS SharePoint). Aber genau das möchte ich auch machen und habe in der c't auch mal einen Artikel gelesen, den ich aber noch nicht ganz verstanden habe. Bin jetzt im Besitz eines Raspberry Pi und habe mir hier mit der Osteraktion einen root Server geholt.


    Debian 9 Stretch installiert, einen Benutzer angelegt un der SUDO Gruppe hinzugefügt, root Login deaktiviert, RSA Key für den Benutzer aktiviert, fail2ban und iptables konfiguriert. Somit sollte er gut geschützt sein, soweit ich mich eingelesen habe. Die Pakete aktualisiere ich noch händisch.


    Ich wechsle im Mai zu einem neuen Internetprovider, bei dem ich keine öffentliche IPv4 mehr bekomme. Ich greife aber sehr gerne über eine VPN Verbindung gegen meine FRITZ!Box auf mein NAS zu. Das wird in Zukunft ja nicht mehr funktionieren. Die Idee laut c't Artikel und wie wohl auch von Pappy gemacht, ich baue von meinem Raspberry einen SSH Tunnel auf zum Linux Server, somit muss ich mich mit meinem Handy (iOS) nun per VPN auf meinen Linux Server verbinden, damit ich in mein Netzwerk komme. Also muss wohl ein VPN Server drauf; einer für die Verbindung vom Handy und der andere vom Raspberry. Der vom Handy sollte auf jeden Fall IPSec VPN sein, da es von iOS bereits integriert ist. Stimmt mein Gedankengang soweit? Wie muss ich das aufsetzen? Bin für sämtliche Vorschläge dankbar.


    Grüße,

    Stefan

  • Für IPSec in Verbindung mit L2TP kann ich Softether empfehlen. Nutze ich selbst auch auf meinem Server. Bietet mehrere Protokolle an, u. a. openVPN und wie schon erwähnt L2TP/IPSec und das eigene Protokoll, dass man mit dem Softether Client nutzen kann. Die Software lässt sich über das Management Tool von einem Remote Computer aus einfach konfigurieren. Ist immer schnell aufgesetzt, schnell konfiguriert und läuft bei mir bisher problemlos.

    Ich kann gerne eine Anleitung zur einfachen Einrichtung zur Verfügung stellen.

  • So ich habe es nun mit mtu 1400 und mss 1300 getestet und es gab keine Besserung. Beim Test mit mtu 1350 und mss 1250 kann ich mich gar nicht mehr vom Handy mit dem Server verbinden.

    Prinzipiell möchte ich ja genau das gleiche machen wie Stefan. Da Android auch IPSec unterstützt, bin ich am überlegen alles auf Anfang zu setzen und auf die selbe Art zu realisieren. Also für die Anleitung hänge ich mich einfach mal an.

  • So ich habe es nun mit mtu 1400 und mss 1300 getestet und es gab keine Besserung. Beim Test mit mtu 1350 und mss 1250 kann ich mich gar nicht mehr vom Handy mit dem Server verbinden.

    Prinzipiell möchte ich ja genau das gleiche machen wie Stefan. Da Android auch IPSec unterstützt, bin ich am überlegen alles auf Anfang zu setzen und auf die selbe Art zu realisieren. Also für die Anleitung hänge ich mich einfach mal an.

    In welcher Richtung bricht das ganze ab? Was für einen Provider hast du zuhause? Ich habe das ganze bei einem Kunden laufen und trotz DSLite Zugang funktioniert das ganze mit mssfix 1350 gut.