Backup schlägt fehl und das Repository (FTPS) bleibt gesperrt [GELÖST]

[JensE]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Ich bin mir nicht sicher, ob das Problem direkt an KeyHelp liegt, aber das Auftreten des Problems war zeitgleich mit dem letzten Update von KeyHelp

Server-Betriebssystem + Version
Betriebssystem Debian 11.7 (64-bit)
KeyHelp 23.1.1 (Build 3016)
FTP-Server ProFTPD 1.3.7a

Problembeschreibung / Fehlermeldungen
Ich betreibe mehrere Server mit Keyhelp. Bei jedem Server sind mehrere Backups über KeyHelp konfiguriert. Diese Server benutzen den selben Backup-Server, auf dem ebenfalls Keyhelp läuft. Der Backup-Server ist als ftps-Repository bei den "Clients" eingerichtet.
Soweit so gut, würde es nicht immer wieder sporadisch zu Problemen kommen, bei denen das Repository gesperrt bleibt und alle Folgeaktionen dadurch fehlschlagen.

Daher bin ich auf die Suche gegangen, was los ist und folgendes Szenario stellt sich dar:
Der FTP-Dienst auf dem Backup-Server (proftpd) blockiert immer wieder Verbindungen mit der Fehlermeldung:

Code: Select all

SECURITY VIOLATION: Passive connection from foreign IP address <IPv6-1> rejected (does not match client IP address <IPv6-2>).

Die IP-Adressen sind unterschiedlich und daher wird die Verbindung verweigert, was ja auch gut und richtig ist.
Das seltsame daran ist jedoch, dass die IP-Adressen von zwei verschiedenen Clients stammen.
Client 1 versucht die Verbindung zum Backup-Server herzustellen und diese bricht mit einem Timeout ab.
Client 2 versucht zeitgleich ebenfalls eine Verbindung herzustellen und diese bricht ebenfalls mit einem Timeout ab.
proftpd auf dem Backup-Server bricht die Verbindung ab, weil die IP-Adresse von Client 1 nicht zur IP-Adresse von Client 2 passt.
Der proftpd scheint hier zwei Verbindungen zu mixen.
In KeyHelp bleibt dann das Repositiory bei den Clients gesperrt...

Kann sich jemand von euch einen Reim darauf machen, was da passiert?
Ich hänge mal das log vom Backup-Server mit an:

/var/log/proftpd/proftpd.log

Code: Select all

2023-06-25 21:00:29,375 BACKUP_SERVER proftpd[197943] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): mod_tls/2.9: unexpected OpenSSL error, disconnecting
2023-06-25 21:00:29,381 BACKUP_SERVER proftpd[197943] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): notice: user CLIENT_1: aborting transfer: Data connection closed
2023-06-25 21:00:29,720 BACKUP_SERVER proftpd[197956] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): mod_tls/2.9: unexpected OpenSSL error, disconnecting
2023-06-25 21:00:29,720 BACKUP_SERVER proftpd[197956] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): notice: user CLIENT_1: aborting transfer: Data connection closed
2023-06-25 21:01:14,304 BACKUP_SERVER proftpd[197965] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): SECURITY VIOLATION: Passive connection from foreign IP address CLIENT_2_IP rejected (does not match client IP address CLIENT_1_IP).
2023-06-25 21:05:48,709 BACKUP_SERVER proftpd[198895] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): notice: user CLIENT_1: aborting transfer: Link to file server lost
2023-06-25 21:06:15,561 BACKUP_SERVER proftpd[198027] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): mod_tls/2.9: unexpected OpenSSL error, disconnecting
2023-06-25 21:06:33,953 BACKUP_SERVER proftpd[197965] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): SECURITY VIOLATION: Passive connection from foreign IP address CLIENT_2_IP rejected (does not match client IP address CLIENT_1_IP).
2023-06-25 21:10:36,919 BACKUP_SERVER proftpd[197965] BACKUP_SERVER (CLIENT_1[CLIENT_1_IP]): Data transfer stall timeout: 600 seconds
2023-06-25 21:11:15,815 BACKUP_SERVER proftpd[198035] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): Data transfer stall timeout: 600 seconds
2023-06-25 21:16:24,697 BACKUP_SERVER proftpd[198978] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): Passive data transfer failed, possibly due to network issues
2023-06-25 21:16:24,697 BACKUP_SERVER proftpd[198978] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): Check your PassivePorts and MasqueradeAddress settings,
2023-06-25 21:16:24,697 BACKUP_SERVER proftpd[198978] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): and any router, NAT, and firewall rules in the network path.
2023-06-25 21:16:24,697 BACKUP_SERVER proftpd[198978] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): FTP no transfer timeout, disconnected
2023-06-25 21:21:15,928 BACKUP_SERVER proftpd[199806] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): Passive data transfer failed, possibly due to network issues
2023-06-25 21:21:15,928 BACKUP_SERVER proftpd[199806] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): Check your PassivePorts and MasqueradeAddress settings,
2023-06-25 21:21:15,928 BACKUP_SERVER proftpd[199806] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): and any router, NAT, and firewall rules in the network path.
2023-06-25 21:21:15,929 BACKUP_SERVER proftpd[199806] BACKUP_SERVER (CLIENT_2[CLIENT_2_IP]): FTP no transfer timeout, disconnected

[Tobi]

ProFTPD „mixt“ mit Sicherheit keine Verbindungen. Das wäre ja fatal…

Viel wahrscheinlicher wird die maximale Anzahl von Verbindungen pro User überschritten und dann ist halt Ende Gelände.

Möglichkeit 1:
Nur mal eine einzige Sicherung machen. Läuft die durch?

Möglichkeit 2:
Nicht alle Backups einem User zuordnen sondern für jedes Backup einen eigenen Ziel-User anlegen.

[JensE]

Hallo Tobi,
danke für deine Antwort. Ich hoffe doch auch, dass proftp da nichts mixt. Aber wo ist die Verbindung zwischen den Clients? Warum will Client 1 eine passive Verbindung vom Backup-Server zu Client 2 aufbauen und nicht zu sich selbst?
Auf dem Backup-Server ist ein einziger User in KeyHelp eingerichtet und für jeden Client ein separates FTP-Konto.
Der Gedanke dahinter ist, dass, sollten die Zugangsdaten von einem Client bekannt werden, kein Zugriff auf die anderen Client-Backups möglich ist.

Es laufen pro Client 3 Backups täglich. Das läuft ein paar Tage gut und dann kommt dieser Fehler. Und das sind auch nicht immer die selben Clients.
Immer mal wieder geht ein Backup auf "Störung", weil dadurch das Repository gesperrt bleibt und ich diese Sperre manuell löschen muss.

500 gleichzeitige Verbindungen und ein Port-Range von 2000 Ports für PassivePorts sollten doch für knapp 20 Clients ausreichen. Außerdem käme da auch eine andere Fehlermeldung.
Die Clients untereinander kennen sich nicht. Nur der Backup-Server kennt die Clients, von denen aber jeder seine eigenen Zugangsdaten hat.

Zudem ist auf dem Backup-Server der Zugriff auf FTP nur von den IPs der Clients aus möglich, da alle anderen Verbindungen von der Firewall geblockt werden.

Was aber auch ist, es laufen alle Backups zur selben Zeit los. Es darf aber doch auch nicht sein, dass, wenn zwei Server Ihre Backups gleichzeitig starten, die IP-Adressen vertauscht werden oder so. Zudem ist es auffällig, dass die Backups nicht schon beim Backup selbst auf "Störung" gehen, sondern erst beim Validieren oder Bereinigen danach...

[JensE]

Heute mal wieder ein Problem beim Backup...
Backup auf ftps-Repository erstellen - erfolgreich
Repository bereinigen - erfolgreich
Integritätsprüfung / Statistiken aktualisieren - beendet mit Fehlern

Fehlermeldung:
Failed to update snapshots: Fatal: unable to create lock in backend: repository is already locked exclusively by PID 592828 on CLIENT_DOMAINcl by root (UID 0, GID 0)
lock was created at 2023-06-29 03:15:24 (9.703816789s ago) storage ID 73d63883
Failed to update stats

Im Log des FTP-Servers ist dazu folgendes zu sehen (/var/log/proftpd/proftpd.log):

Code: Select all

2023-06-29 03:05:12,618 FTP_SERVER_NAME proftpd[11847] FTP_SERVER_NAME (CLIENT_DOMAIN_1[CLIENT_IP_1]): mod_tls/2.9: unexpected OpenSSL error, disconnecting
2023-06-29 03:05:12,619 FTP_SERVER_NAME proftpd[11847] FTP_SERVER_NAME (CLIENT_DOMAIN_1[CLIENT_IP_1]): notice: user CLIENT_DOMAIN_1: aborting transfer: Data connection closed
2023-06-29 03:05:15,087 FTP_SERVER_NAME proftpd[11860] FTP_SERVER_NAME (CLIENT_DOMAIN_1[CLIENT_IP_1]): notice: user CLIENT_DOMAIN_1: aborting transfer: Link to file server lost
2023-06-29 03:05:15,698 FTP_SERVER_NAME proftpd[11861] FTP_SERVER_NAME (CLIENT_DOMAIN_1[CLIENT_IP_1]): notice: user CLIENT_DOMAIN_1: aborting transfer: Link to file server lost
2023-06-29 03:05:25,287 FTP_SERVER_NAME proftpd[11011] FTP_SERVER_NAME (CLIENT_DOMAIN_1[CLIENT_IP_1]): SECURITY VIOLATION: Passive connection from foreign IP address CLIENT_IP_2 rejected (does not match client IP address CLIENT_IP_1).

Auch hier wieder zu sehen, dass die Client-IPs gemixt werden...

Eine andere Fehlermeldung, die auch auft ist:
Repository bereinigen - Abgebrochen

Code: Select all

Failed to prune repository: /restic/cmd/restic/cmd_forget.go:35
github.com/spf13/cobra.(*Command).execute
/home/build/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:916
github.com/spf13/cobra.(*Command).ExecuteC
/home/build/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:1044
github.com/spf13/cobra.(*Command).Execute
/home/build/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:968
github.com/spf13/cobra.(*Command).ExecuteContext
/home/build/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:961
main.main
/restic/cmd/restic/main.go:96
runtime.main
/usr/local/go/src/runtime/proc.go:250
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1598

[Florian]

Hallo,

mal mit

Code: Select all

AllowForeignAddress on

im ProftpD getestet?

[JensE]

Nein, das habe ich nicht.
Dadurch würde vermutlich der Fehler mit der SECURITY VIOLATION verschwinden.
Was ich dennoch nicht verstehe ist, warum proftpd für Client1 eine Verbindung vom FTP-Server zu Client2 aufbauen sollte.
Das ergibt keinen Sinn und sollte ja auch unterbunden werden.
Was will denn Client1 mit einer passiven Verbindung vom FTP-Server zu einem für ihn fremden Rechner?

[JensE]

Ein kurzes Update zu dieser Problematik:
Wenn ich das richtig verstanden habe ist ein Bug in proftp 1.3.7a für das Problem verantwortlich, der die Passive Ports mehrfach vergibt, wenn mehrere Server gleichzeitig eine Verbindung aufgebaut haben...
Wer das nachlesen will, hier der Link zur Beschreibung: https://github.com/proftpd/proftpd/issues/1171

Mit Debian 12 und der Version 1.3.8 von proftp sollte der Bug gefixt sein.
Ich habe noch nicht alle Server auf Debian 12 aktualisiert. Daher kann ich das noch nicht bestätigen.

[JensE]

Nun sind alle Server auf Debian 12 migriert und ich kann bestätigen, dass der Fehler nicht mehr auftritt.