2
SMB Sharing via NAT (Masquerading) und VPN
Wie erreicht man aus einem "maskierten" Netzwerk einen SMB-Server und baut eine Verbindung zu einer Freigabe auf?
Hallo zusammen!
Folgendes Szenario macht Probleme.
Zunächst nocht ganz einfach:
-Privtes Heimnetz (192.168.0.0/24) mit Windows und Linux Clients.
-Linux (2.4.10er Kernel) Server mit Samba und DSL Verbindung.
-Linux-Server hat die iptables Firewall laufen mit der die DSL-Verbindung via MASQUERADING frei gegeben wird (zusätzlich läuft Squid als Proxy-Server)
Auch noch logisch:
-Der Server baut eine VPN-Verbingung zu einem Fernnetzwerk auf. Dieses Netz hat echte IP's (nicht privat).
-Die Internetverbindung läuft weiter direkt über DSL (nicht Durch den VPN-Tunnel).
Das Problem kommt näher:
-Eine Route vom Heimnetz zum Netzwerk hinter dem VPN ist im Kernelrouter eingetragen.
-Diese bringt logischerweise nicht viel da die Pakete mit privaten (192.168.*.*) IP's von einem Router in einem "echten" Netz nicht weitergeleitet werden
(ist zwar kein muss aber sinnvoll und in diesem Fall auch so).
Und jetzt wird's tricky:
-Um dieses Problem loszuwerden habe ich eine weitere "MASQUERADING" Rule in die iptables Firewall eingesetzt,
die den Traffic zum virtuellen Netzwerkport (der VPN-Schnittstelle) ebenfals Maskiert.
-Funktioniert! --> Jubel!
Und jetzt das Problem:
-Der eigentliche Sinn und zweck der Sache war es eine SMB Freigabe (bzw. drei) die auf einem Server (müsste win2k3Server sein)
in dem Netzwerk hinter dem VPN-Tunnel liegt als Netzlaufwerk zu verbinden.
-Der Server ist erreichbar und Verlangt eine Identiifizierung.
-Allerdings schlägt diese jedesmal fehl (Beim Laden ist ein fehler aufgetreten, Zugriff verweigert!) --> Heul!
Ich kann mir dies nur so erklären, das bei der Identifikation der SMB Server und der Client auf einer höheren OSI-Schicht im SMB Protokoll eine neue Verbindung aushandeln.
Das iptables "SNAT-DNAT/PAT" arbeitet ja nur auf der Schicht 3+4. Für FTP usw. gibt es für dieses Problem extra Kernelmodule die das "NAT" in den Oberen Schichten übernimmt.
Für SMB scheint es leider keines zu geben.
Wenn die VPN-Client Software auf einem der Clientrechner (192.168.0.*) läuft funktioniert die Verbindung (klar dann hat der Client ja auch ein eigenes virtuelles Interface mit der "richtigen" IP.
Das hilft mir jedoch nicht wirklich weiter, da ich die 3 Freigaben von 3 verschiedenen Clients Nutzen will und mehere VPN-Verbindungen über die gleiche IP (die zum DSL Interface des Servers) nicht zulässig sind (der VPN-Server schreibt den Port vor) und desshalb immer nur eine Verbindung bestehen könnte.
Schonmal vielen herzlichen Dank en jeden der dashier überhaupt bis zum Ende durchliest.
Wenn jemand eine Idee hat wie man dieses Problem lösen könnte, egal wie doof sie klingen mag, bitte postet sie hier!
MfG linuxleuser
Hallo zusammen!
Folgendes Szenario macht Probleme.
Zunächst nocht ganz einfach:
-Privtes Heimnetz (192.168.0.0/24) mit Windows und Linux Clients.
-Linux (2.4.10er Kernel) Server mit Samba und DSL Verbindung.
-Linux-Server hat die iptables Firewall laufen mit der die DSL-Verbindung via MASQUERADING frei gegeben wird (zusätzlich läuft Squid als Proxy-Server)
Auch noch logisch:
-Der Server baut eine VPN-Verbingung zu einem Fernnetzwerk auf. Dieses Netz hat echte IP's (nicht privat).
-Die Internetverbindung läuft weiter direkt über DSL (nicht Durch den VPN-Tunnel).
Das Problem kommt näher:
-Eine Route vom Heimnetz zum Netzwerk hinter dem VPN ist im Kernelrouter eingetragen.
-Diese bringt logischerweise nicht viel da die Pakete mit privaten (192.168.*.*) IP's von einem Router in einem "echten" Netz nicht weitergeleitet werden
(ist zwar kein muss aber sinnvoll und in diesem Fall auch so).
Und jetzt wird's tricky:
-Um dieses Problem loszuwerden habe ich eine weitere "MASQUERADING" Rule in die iptables Firewall eingesetzt,
die den Traffic zum virtuellen Netzwerkport (der VPN-Schnittstelle) ebenfals Maskiert.
-Funktioniert! --> Jubel!
Und jetzt das Problem:
-Der eigentliche Sinn und zweck der Sache war es eine SMB Freigabe (bzw. drei) die auf einem Server (müsste win2k3Server sein)
in dem Netzwerk hinter dem VPN-Tunnel liegt als Netzlaufwerk zu verbinden.
-Der Server ist erreichbar und Verlangt eine Identiifizierung.
-Allerdings schlägt diese jedesmal fehl (Beim Laden ist ein fehler aufgetreten, Zugriff verweigert!) --> Heul!
Ich kann mir dies nur so erklären, das bei der Identifikation der SMB Server und der Client auf einer höheren OSI-Schicht im SMB Protokoll eine neue Verbindung aushandeln.
Das iptables "SNAT-DNAT/PAT" arbeitet ja nur auf der Schicht 3+4. Für FTP usw. gibt es für dieses Problem extra Kernelmodule die das "NAT" in den Oberen Schichten übernimmt.
Für SMB scheint es leider keines zu geben.
Wenn die VPN-Client Software auf einem der Clientrechner (192.168.0.*) läuft funktioniert die Verbindung (klar dann hat der Client ja auch ein eigenes virtuelles Interface mit der "richtigen" IP.
Das hilft mir jedoch nicht wirklich weiter, da ich die 3 Freigaben von 3 verschiedenen Clients Nutzen will und mehere VPN-Verbindungen über die gleiche IP (die zum DSL Interface des Servers) nicht zulässig sind (der VPN-Server schreibt den Port vor) und desshalb immer nur eine Verbindung bestehen könnte.
Schonmal vielen herzlichen Dank en jeden der dashier überhaupt bis zum Ende durchliest.
Wenn jemand eine Idee hat wie man dieses Problem lösen könnte, egal wie doof sie klingen mag, bitte postet sie hier!
MfG linuxleuser
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: 21164
Url: https://administrator.de/forum/smb-sharing-via-nat-masquerading-und-vpn-21164.html
Ausgedruckt am: 23.12.2024 um 16:12 Uhr
2 Kommentare
Neuester Kommentar
Hallo zusammen!
Folgendes Szenario macht Probleme.
Zunächst nocht ganz einfach:
-Privtes Heimnetz (192.168.0.0/24) mit
Windows und Linux Clients.
-Linux (2.4.10er Kernel) Server mit Samba
und DSL Verbindung.
-Linux-Server hat die iptables Firewall
laufen mit der die DSL-Verbindung via
MASQUERADING frei gegeben wird
(zusätzlich läuft Squid als
Proxy-Server)
Auch noch logisch:
-Der Server baut eine VPN-Verbingung zu
einem Fernnetzwerk auf. Dieses Netz hat
echte IP's (nicht privat).
-Die Internetverbindung läuft weiter
direkt über DSL (nicht Durch den
VPN-Tunnel).
Das Problem kommt näher:
-Eine Route vom Heimnetz zum Netzwerk hinter
dem VPN ist im Kernelrouter eingetragen.
-Diese bringt logischerweise nicht viel da
die Pakete mit privaten (192.168.*.*) IP's
von einem Router in einem "echten"
Netz nicht weitergeleitet werden
(ist zwar kein muss aber sinnvoll und in
diesem Fall auch so).
Und jetzt wird's tricky:
-Um dieses Problem loszuwerden habe ich eine
weitere "MASQUERADING" Rule in die
iptables Firewall eingesetzt,
die den Traffic zum virtuellen
Netzwerkport (der VPN-Schnittstelle)
ebenfals Maskiert.
-Funktioniert! --> Jubel!
Und jetzt das Problem:
-Der eigentliche Sinn und zweck der Sache
war es eine SMB Freigabe (bzw. drei) die auf
einem Server (müsste win2k3Server sein
ich nehme mal an das w2k3 ADintegriert ist,Folgendes Szenario macht Probleme.
Zunächst nocht ganz einfach:
-Privtes Heimnetz (192.168.0.0/24) mit
Windows und Linux Clients.
-Linux (2.4.10er Kernel) Server mit Samba
und DSL Verbindung.
-Linux-Server hat die iptables Firewall
laufen mit der die DSL-Verbindung via
MASQUERADING frei gegeben wird
(zusätzlich läuft Squid als
Proxy-Server)
Auch noch logisch:
-Der Server baut eine VPN-Verbingung zu
einem Fernnetzwerk auf. Dieses Netz hat
echte IP's (nicht privat).
-Die Internetverbindung läuft weiter
direkt über DSL (nicht Durch den
VPN-Tunnel).
Das Problem kommt näher:
-Eine Route vom Heimnetz zum Netzwerk hinter
dem VPN ist im Kernelrouter eingetragen.
-Diese bringt logischerweise nicht viel da
die Pakete mit privaten (192.168.*.*) IP's
von einem Router in einem "echten"
Netz nicht weitergeleitet werden
(ist zwar kein muss aber sinnvoll und in
diesem Fall auch so).
Und jetzt wird's tricky:
-Um dieses Problem loszuwerden habe ich eine
weitere "MASQUERADING" Rule in die
iptables Firewall eingesetzt,
die den Traffic zum virtuellen
Netzwerkport (der VPN-Schnittstelle)
ebenfals Maskiert.
-Funktioniert! --> Jubel!
Und jetzt das Problem:
-Der eigentliche Sinn und zweck der Sache
war es eine SMB Freigabe (bzw. drei) die auf
einem Server (müsste win2k3Server sein
dann braucht w2k3 EAP als authentifizierungsprotoll
dieses muß bis zum tunnelanfang am Client ankommen und die Authentifizierung entgegenzunehmen.
in dem Netzwerk hinter dem VPN-Tunnel
liegt als Netzlaufwerk zu verbinden.
-Der Server ist erreichbar und Verlangt eine
Identiifizierung.
ja genau , EAPliegt als Netzlaufwerk zu verbinden.
-Der Server ist erreichbar und Verlangt eine
Identiifizierung.
cu willi
Hallo willi,
ich verstehe nicht ganz warum die Verschlüsselung des Passworts oder das Verfahren dazu
einen Ausschlag geben sollen, die Daten werden ja übermittelt, egal ob verschlüsselt (innerhalb der 5. und 6. Schicht) oder nicht.
Ich habe mittlerweile folgendes in Erfahrung gebracht: Der Server ist nicht wie angenommen ein win2k3 Server sondern ein Linux 2.6.x mit Samba 3.x Server.
Es gab wohl ein Config-Problem am Server, denn heute mittag hat es ohne das ich irgendwas geändert
habe einfach funktioniert, und dort wo der Server steht gab es in den letzten tagen auch Probleme mit den Fileservern. Ich nehme an das die zuständigen Administratoren dort das Problem in den Griff gekriegt haben.
Aber trotzdem vielen Dank für die Mühe.
Ich wüsste trotzdem gern genauer was du mit dem EAP-Problem gemeint hast und wie die Authentifizierung bei SMB funktioniert. (Aus reiner Neugier) Vieleicht hast du ja Zeit das hier mal zu posten.
ich verstehe nicht ganz warum die Verschlüsselung des Passworts oder das Verfahren dazu
einen Ausschlag geben sollen, die Daten werden ja übermittelt, egal ob verschlüsselt (innerhalb der 5. und 6. Schicht) oder nicht.
Ich habe mittlerweile folgendes in Erfahrung gebracht: Der Server ist nicht wie angenommen ein win2k3 Server sondern ein Linux 2.6.x mit Samba 3.x Server.
Es gab wohl ein Config-Problem am Server, denn heute mittag hat es ohne das ich irgendwas geändert
habe einfach funktioniert, und dort wo der Server steht gab es in den letzten tagen auch Probleme mit den Fileservern. Ich nehme an das die zuständigen Administratoren dort das Problem in den Griff gekriegt haben.
Aber trotzdem vielen Dank für die Mühe.
Ich wüsste trotzdem gern genauer was du mit dem EAP-Problem gemeint hast und wie die Authentifizierung bei SMB funktioniert. (Aus reiner Neugier) Vieleicht hast du ja Zeit das hier mal zu posten.
