Ich versuche, Nginx so zu konfigurieren, dass Port 445 als Reverse-Proxy verwendet wird, aber jedes Mal, wenn Client A über Nginx mit der Freigabe verbunden ist und sich Client B verbindet, wird die Verbindung von Client A von Nginx getrennt, obwohl er die Freigabe aktiv verwendet hat (z. B. beim Herunterladen einer großen Datei). Es ist, als würde Nginx die Verbindung für Client B wiederverwenden, bevor Client A sie nicht mehr verwendet.
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log debug;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
stream {
server {
listen 445;
proxy_pass storage:445;
}
}
Was fehlt in der obigen Konfigurationsdatei, um sowohl Client A als auch Client B die gleichzeitige Nutzung der Freigabe zu ermöglichen, ohne eine Verbindung zu trennen, um die andere aufzubauen?
Einige zusätzliche Informationen:
Nginx v. 1.17.1 läuft auf Ubuntu 18.04.2 LTS, virtuelle Maschine, 4 vCPU und 4 GB Speicher;
Ich habe bereits versucht, diese Steuerung mit iptables statt Nginx durchzuführen, um die Verbindungen auf Port 445 an den Share-Server weiterzuleiten, und das Ergebnis war ähnlich: Die Verbindung von Client A wird unterbrochen, wenn B eine Verbindung herstellt;
Die Freigabe funktioniert einwandfrei, wenn die Clients A und B eine direkte Verbindung zur Speicherfreigabe herstellen, ohne dass Nginx dazwischen geschaltet ist.
Ich habe ziemlich viele der empfohlenen Konfigurationen aus der Nginx-Dokumentation ausprobiert (limit_conn, so_keepalive, reuseport …), aber ich habe sie möglicherweise falsch verwendet.
In Wireshark sehe ich, dass Nginx ein [FIN, ACK]-Paket an Client A sendet, wenn Client B eine Verbindung herstellt.
Protokoll von Nginx, wenn die Verbindung von Client A beeinträchtigt ist: *[Fehler] 32110#32110:7 recv() ist fehlgeschlagen (104: Verbindung vom Peer zurückgesetzt) beim Proxying und Lesen vom Upstream ... aber mir fällt auf, dass dieses Protokoll mit einem [RST, ACK]-Paket zusammenhängt, das Client A an Nginx sendet, selbst nachdem er das [FIN, ACK]-Paket empfangen hat.
Bearbeiten:
Mit der neueren Version 1.17.3 versucht, ohne Erfolg.
Antwort1
Ich denke, der SMB-Server wird Ihre Verbindung trennen, weil dieselbe Maschine von seiner Seite aus versucht, eine Verbindung mit verschiedenen Benutzern herzustellen. Dasselbe gilt für die Verwendung von Masquerade mit iptables und Nginx.
Ich würde weiterhin iptables verwenden, aber ohne den Datenverkehr zu Ihrem SMB-Server zu maskieren und nur die Weiterleitung zuzulassen.
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 445 -j DNAT --to-destination storage:445
iptables -t filter -A FORWARD -d storage/32 -p tcp -m tcp --dport 445 -j ACCEPT
Sorgen Sie dafür, dass der Datenverkehr von Ihrem SMB-Server zu den Netzwerken, in denen sich die Clients befinden, über den Proxy-/Weiterleitungsserver geleitet wird.
Anschließend müssen Sie im Proxy-/Weiterleitungsserver den Datenverkehr zu den Netzwerken Ihrer Clients maskieren. Beispiel:
iptables -t nat -A POSTROUTING -d 192.168.0.0/24 -o eth0 -j MASQUERADE
Damit empfängt der SMB-Server Datenverkehr von den IPs des Clients, während die Kommunikation des Clients mit dem Proxy-/Weiterleitungsserver erfolgt und die Verbindung nicht unterbrochen werden sollte, wenn mehrere Clients eine Verbindung herstellen.