Storage space kann nicht gemounted werden

  • Hay,


    irgendwas ist mit dem Storagehost an sich, es muss mit dessen Einstellungen zu tun haben, voraussichtlich Netzwerk (gefühlt etwas mit dem Rück-Routing) auch wenn alles zu funktionieren scheint. Kannst Du vom Storagehost zum Client pingen? Wie hast Du den denn in Dein VLAN gebracht? Hast Du eine Anbindung außerhalb des VLANs einmal probiert?


    Vielleicht zuerst auch mal anderes Protokoll probieren - wenn es das allerdings wäre, würde man von dem Problem öfters lesen...


    Code
    1. mount -t nfs -o nfsvers=3 ....

    Anschließend ratlos :P


    CU, Peter

  • Danke erst einmal dafür, dass du noch dabei bist ;) - Die Antwort vom Support ist noch ausstehend. Ich habe mal ein tracert gemacht. Der geht zum Host durch. Der Aufbau ist ja WinSrv2016->pfsense->WAN D.h. zwischen WinSrv2016 und pfsense ist die Verbindung um das VLAN realisiert. Komisch ist halt, dass ich den Host erreiche und dann nur auf meinen Share nicht zugreifen kann. Ping geht auch durch. Ich hab auch mal im Log der Firewall geguckt, ob ggf. doch iwas zurück geroutet wird und dann geblockt wird. Konnte aber nichts finden. Mal abgesehen, davon das der kram mit der pfsense ja statefull ist.


    Ich hab auch schon mal versucht außerhalb des VLAN zuzugreifen.

    Mal eine doofe Frage. Ich habe das ganze überflogen. Wo genau steht die FW? wird alles über die pfsense geroutet?

    Jap geht alles über die pfsense. D.h. der Server greift quasi mit der IP einer anderen VPS zu. Diese habe ich aber auch freigegeben.


    Grundsätzlich kann ich mir mittlerweile einen Fehler auf meiner Seite nicht mehr vorstellen, weil ich den Host erreiche und sogar per NFS drauf zu greifen kann. Nur sobald ich in mein Share / Unterverzeichnis möchte, bekomme ich ein AccessDenied.

  • Hab gerade ein anderes Protokoll versucht und erhalte den gleichen Fehler. Permission denied.

  • Da du alles durch dir pfsense routest, was hast du da für Einstellungen? NFS braucht ein paar ports. Es kommt halt auch auf die Config von netcup an. Hast du ein NAT auf der FW?

    Naja Grundsätzlich darf erst einmal nichts von außen rein. Dann hab ich einen Alias RFC1918 erstellt. Dort alle privaten IP-Adressebereiche rein gepackt und dann eine Regel gebaut, welche übergreifend auf den internen Interfaces liegt und alle am Interface eingehenden Verbindungen, die nicht den privaten IP-Adressenbereichen (Alias negiert) entsprechen über das Gateway geroutet werden (Policy-Routing). So unter NAT ist ein Outbound-NAT eingerichtet. Da der Storagespace auf einer Public-IP liegt, geht die Anfrage also über das WAN Interface raus. Und da ich ja auch auf \\HOST-IP\ zugreifen kann und dann alle Shares sehe ist die Erreichbarkeit ja sichergestellt.

  • Es ist halt ein Unterschied ob du das Share erreichen oder mounten kannst. NFS ist halt etwas eigen. Es gibt auch Configs da musste man von einem Source Port unter 1024 kommen (bezogt sich auf NFS Secure oder so) Mein letzter Einsatz von NFS ist schon "etwas" her.

    Ein Test wäre ein nfs client auf der pfsense und dann testen. Es liegt an der FW. Du müsstest Netcup mal fragen, ob die eine statische Portconfig für NFS haben.

    Auch wenn das funktionert, kann die Performance Aufgrund der FW sehr leiden.

  • Es ist halt ein Unterschied ob du das Share erreichen oder mounten kannst. NFS ist halt etwas eigen. Es gibt auch Configs da musste man von einem Source Port unter 1024 kommen (bezogt sich auf NFS Secure oder so) Mein letzter Einsatz von NFS ist schon "etwas" her.

    Ein Test wäre ein nfs client auf der pfsense und dann testen. Es liegt an der FW. Du müsstest Netcup mal fragen, ob die eine statische Portconfig für NFS haben.

    Auch wenn das funktionert, kann die Performance Aufgrund der FW sehr leiden.

    Grundsätzlich klingt das logisch, auch wenn ich alles technisch nicht ganz beurteilen kann. Da ich es aber auch von einer VPS versucht habe, welche direkt über das WAN-Interface und nicht über die pfsense geht, ist es ja ausgeschlossen das es an der pfsense liegt.


    Ich mach jetzt noch einmal folgendes. Ich installiere mal irgendein Standard-Image von Netcup, greife über das WAN direkt zu und schau mal ob das geht.

  • Grundsätzlich klingt das logisch, auch wenn ich alles technisch nicht ganz beurteilen kann. Da ich es aber auch von einer VPS versucht habe, welche direkt über das WAN-Interface und nicht über die pfsense geht, ist es ja ausgeschlossen das es an der pfsense liegt.

    So nebenbei: https://forum.netgate.com/topi…ecure-nfs-v4-nat-router/2

    https://www.reddit.com/r/homel…t/nfs_behind_firewallnat/

    ░▒▓Blog: https://grundsoli.de/▓▒░

    ░▒▓Gutscheine: https://netcup-groupie.de/▓▒░

  • Es funktioniert, wenn ich ein Debian-Standard Image von Netcup nehme, welches direkt über die Public IP mit dem NFS Storage spricht. Warum das bei dem Windows 10 nicht funktioniert hat, führe ich jetzt mal auf eine Fehler meinerseits zurück.


    So das heißt der Storage ist in Ordnung. Ich hab dann gestern mit der funktionierenden VM geprüft und mir mal ein paar Artikel über NFS reingezogen. Bis Version 3 (da läuft viel mit UDP) scheint das ein ganz schöner Krampf zu sein. Ab Version 4 wird auf TCP gesetzt und damit soll das einfacher sein. Netcup scheint NFS in der Version 3 zu nutzen. Beim Versuch per Vers=4 eine Verbindung aufzubauen. Hab ich eine Fehlermeldung bekommen das das Protokoll falsch wäre.


    Ich hab die genaue Konfig noch nicht raus, aber es liegt definitiv an dem Umstand das ich eine Firewall davor habe. :pinch: (Auch wenn nichts geblockt wird).


    Ich schau mir das noch mal an (auch den Hinweis mit den UDP-Ports).


    VG und danke für die ausdauernde Hilfe!! :) Das Ergebnis landet definitiv hier im Forum.

  • HUHU,


    so ich bekomme nun eine Verbindung zum Server!!!!


    Hierfür war folgende Config (neben dem normalen Outbound NAT) nötig:

    Schnittstelle Quelle Quellport Ziel Zielport NAT-Adresse NAT-Port Statischer Port
    WAN IPCLIENT/32 tcp/udp/* STORAGEIP/32 tcp/udp/ 635 WAN address * YES
    WAN IPCLIENT/32 tcp/udp/* STORAGEIP/32 tcp/udp/ 111 WAN address * YES


    Ich hab mir nen Hintern voll Artikel dazu durchgelesen und dabei ist die obige Config bei rausgekommen. Nur technisch habe ich das Thema noch nicht durchdrungen.


    Per Netstat habe ich gesehen, dass für das NFS scheinbar folgende Verbindungen dauerhaft aufgebaut werden:

    TCP IPCLIENT:XXX STORAGEIP:4045 HERGESTELLT

    TCP IPCLIENT:XXX STORAGEIP:2049 HERGESTELLT


    Damit hatte ich keine Probleme das ging so durch die Firewall durch. Was auch dafür spricht, dass ich den Server als \\STORAGEIP\ aufrufen konnte und die ganzen Shares sehen konnte. Für den Share habe ich folgendes beobachtet:

    UDP IPCLIENT:XXX STORAGEIP:635 SYNC WARTEND

    UDP IPCLIENT:XXX STORAGEIP:111 SYNC WARTEND


    Nach dem Hinzufügen der dedizierten Outbound-NAT-Regeln (siehe oben). Hat es dann funktioniert und die Verbindung steht. Warum ich diese Konfig jetzt genau vornehmen musste hab ich nicht zu 100% verstanden. Die Pakete des Clients geht über einen Random-UDP-Port an die STORAGEIP über UDP 111 und 635. Ich weiß grob was NAT ist aber nicht so im Detail das ich jetzt wüsste was da passiert.


    Kann mir das abschließend jemand erklären oder kennt jemand eine Seite, auf der das hübsch erklärt wird? Gerne mit Bildchen :saint:


    Danke Euch und VG

    Green14


    PS: Wo kann ich das mal als Anleitung zusammenschreiben oder finden andere die Lösung hier? Die Überschrift passt ja jetzt nicht mehr unbedingt.

  • ah, klar. 111 ist rpcbind - der ist zumindest für nfs2/3 zwingend erforderlich. M.W. (lass mich gern verbessern) bekommt der Client über rpc die Portnummern der beteiligten Dienste. Ich hasse das Teil - schon genug Stress mit gehabt ;-)

    Gruss