FTP-Server kann SSL-Handshake nicht abschließen (VSFTPD)

1390
mr_johnson22

Ich versuche, einen über das Internet zugänglichen FTP-Server mit Verschlüsselung unter Verwendung von VSFTPD als Serverprogramm auf Fedora 25 einzurichten. Obwohl ich scheinbar alles richtig eingerichtet habe, kann ich niemals eine Verbindung zum Server von außerhalb meines LANs herstellen, wenn die Verschlüsselung aktiviert ist. Die Verbindung ist jedoch möglich, wenn ich die Verschlüsselung inaktiviere oder eine Verbindung von meinem LAN aus herstelle.

Mein Problem ist, dass der VSFTPD-Server den SSL-Handshake nicht abschließen kann, nachdem er den AUTH-Befehl von einem Client erhalten hat. Mit Wireshark kann ich sehen, dass der Server mehrmals versucht, eine so genannte Handshake-Antwort zu senden.

Wenn es hilft, hier der Bericht von Wireshark, dass ein Client versucht, eine Verbindung zum Server herzustellen:

From Info ------ ---- Client 64423 → 21 [ACK] Seq=1 Ack=1 Win=13952 Len=0 TSval=996262 TSecr=3062736173 Server Response: 220 (vsFTPd 3.0.3) Client 64423 → 21 [ACK] Seq=1 Ack=21 Win=13952 Len=0 TSval=996281 TSecr=3062736371 Client Request: AUTH TLS Server 21 → 64423 [ACK] Seq=21 Ack=11 Win=29056 Len=0 TSval=3062736436 TSecr=996282 Server Response: 234 Proceed with negotiation. Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062736822 TSecr=996282 Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282 Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282 Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062737214 TSecr=996282 ...

Weitere Informationen: Ich habe VSFTPD für die Verwendung von TLSv1 oder höher konfiguriert, um im passiven Modus mit explizitem FTPS und mit einem selbstsignierten RSA-Zertifikat zu arbeiten. Ich glaube nicht, dass es ein Problem mit meinem Zertifikat gibt, da ich mit demselben Zertifikat einen https-Server mit httpd hosten kann, auf den ich von außerhalb meines LAN zugreifen kann. Also muss das Problem irgendwie mit VSFTPD zusammenhängen.

Ich habe auch meinen Router und meine Firewall so eingestellt, dass er Port 21 für FTP-Steuerungsanschlüsse weiterleitet und akzeptiert. Ich habe auch VSFTPD so eingestellt, dass Port 2048 als einziger PASV-Datenport verwendet wird, aber aus irgendeinem Grund musste ich diesen Port an meinem Router nicht weiterleiten, damit unverschlüsselte FTP-Verbindungen funktionieren ... und außerdem liegt der Fehler, den ich habe passiert, bevor der Datenport beteiligt ist.

Hat jemand eine Idee, wie man das beheben kann? Gibt es etwas offensichtliches, das mir hier fehlt?

1
Schlagen Sie vor, das Debug-Protokoll auf VSFTPD zu aktivieren, und suchen Sie dort nach dem Grund. Für die Referenz: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-ftp-vsftpd-conf.html Oleg vor 7 Jahren 1
Vielen Dank. Wenn ich die Protokollierung und das SSL-Debugging aktiviere, fügt meine Datei vsftpd.log bei jedem Verbindungsversuch diese Zeilen hinzu und schlägt fehl: `CONNECT: Client" :: ffff:"DEBUG: Client" :: ffff:"," SSL_accept fehlgeschlagen: Fehler: 00000000: lib (0): func (0): Grund (0) "` mr_johnson22 vor 7 Jahren 0

1 Antwort auf die Frage

1
Steffen Ullrich 
Server Response: 234 Proceed with negotiation. Server [TCP Retransmission] 21 → 64423 [PSH, ACK] Seq=21 Ack=11 Win=29056 Len=31 TSval=3062736822 TSecr=996282

Was Sie sehen, ist nicht der TLS-Handshake. Der TLS-Handshake würde vom Client gestartet, was hier nicht der Fall ist. Stattdessen sehen Sie eine erneute Übertragung der letzten Antwort des Servers, dh 234 Proceed with negotiation.\r\ngenau 31 Byte.
Dies bedeutet, dass der Server keine ACK vom Client zu dieser Antwort erhält und diese daher erneut überträgt, dh das übliche Verhalten von TCP-Verbindungen bei fehlenden ACK.

Die Frage ist, warum der Server die ACK nicht empfängt. Aus Ihrer Frage ist nicht klar, ob die Paketerfassung auf der Client- oder Serverseite durchgeführt wurde. Ich gehe jedoch davon aus, dass sie auf der Serverseite durchgeführt wurde. In diesem Fall würde ich vermuten, dass es eine Firewall zwischen Client und Server gibt, die die Verbindung stört:
Da FTP ein Protokoll mit dynamischen Ports für die Datenübertragung ist und diese dynamischen Ports innerhalb der Steuerungsverbindung ausgetauscht werden, muss eine Firewall Klartext haben Zugriff auf die Steuerungsverbindung, um herauszufinden, welche dynamischen Ports verwendet werden, und diese Ports zu öffnen. Wenn die Steuerverbindung verschlüsselt ist (AUTH TLS), ist dies nicht mehr möglich, sodass einige Firewalls versuchen, die Verwendung von TLS explizit oder unabsichtlich zu blockieren. Und was Sie sehen, könnte das Ergebnis sein.

Ja, das Wireshark-Protokoll wurde serverseitig erstellt. Ich habe auch gerade versucht, eine FTP-Verbindung herzustellen, nachdem ich meine Firewalls kurz ausgeschaltet hatte, und es ist immer noch derselbe Fehler aufgetreten. Es ist also wahrscheinlich kein Firewall-Problem ... aber vielleicht gibt es eine Firewall im LTE-Internet meines Telefons, die ich habe als FTP-Client verwendet. mr_johnson22 vor 7 Jahren 0
@ mr_johnson22: * ... LTE Internet meines Telefons ... * - nicht unwahrscheinlich. Mobile Verbindungen verwenden häufig privates IPv4 in Kombination mit NAT. In diesem Fall muss auch die spezielle Behandlung von FTP durchgeführt werden. Vergleichen Sie einfach die Client-IP, die Sie auf dem Server sehen, mit der IP-Adresse, die Ihr Telefon erhalten hat, um zu sehen, ob dies der Fall ist. Siehe auch https://en.wikipedia.org/wiki/Carrier-grade_NAT Steffen Ullrich vor 7 Jahren 0
Das erklärt die Dinge. (Mein FTP-Server hat dieselbe IP-Adresse wie mein Telefon, aber ich könnte etwas vermissen.) Ich habe auch etwas recherchiert und es sieht so aus, als würden einige Clients / Firewalls FTPS mit selbstsignierten Zertifikaten blockieren. Ich werde stattdessen nur SFTP verwenden. mr_johnson22 vor 7 Jahren 0

Verwandte Probleme