[Risolto] Il Firewall corrompe i files compressi sul server?

Fedora Linux Internet, Reti e Sicurezza
#1

Salve a tutti, si tratta di un problema subdolo, che mi accade da un po’ di tempo (anche dopo aver aggiornato il sistema che ora è 4.7.4-100.fc23.x86_64). Spero di riuscire a spiegarmi bene.

Innanzitutto ho il firewall attivato e in più uso apf (advanced-policy-firewall, https://www.rfxn.com/projects/advanced-policy-firewall/).

Poi: se metto in stop il firewall e poi lo riavvio, devo anche riavviare apf (con un apf -r) altrimenti l’upload non va.

Inoltre uso due linee internet, alternative. Con una delle due linee il problema che sto per descrivere non si verifica mai. Con l’altra, quando carico sul server i miei file .tar.gz (ma succede anche con gli .zip), che hanno dimensione tra i 10 e i 25MB, pur essendo integri in locale (verificato più volte) quando li estraggo sul server li trovo corrotti (accade sia usando lftp che curl -T).

Credevo fosse un problema di linea internet (visto che con l’altra, come dicevo, questo problema non c’è) e invece ho scoperto che se disattivo il firewall:

systemctl stop firewalld

allora 10 volte su 10 i file non si corrompono!

Riepilogando, verificando più volte (decine):

  1. Files compressi in locale: non corrotti
  2. Linea internet A: files mai corrotti dopo upload
  3. Linea internet B con firewalld: files sempre corrotti con errore:

[code]gzip: stdin: invalid compressed data–crc error

gzip: stdin: invalid compressed data–length error
tar: Child returned status 1
tar: Error is not recoverable: exiting now[/code]
4) Linea internet B SENZA firewalld: files mai corrotti dopo upload

Sembra uno scherzo, ma mi accade questo… Possibile che il firewall corrompa i file compressi? E solo per quella linea? Con altri file (carico varie mappe in png e faccio anche molti download) non ho problemi con nessuna delle due linee e con firewall attivato.

Che ne pensate? Vorrei naturalmente evitare di tenere in stop il firewall!

#2

Strano è strano. Hai provato a comparare le lunghezze dei file e vedere se magari qualcosa si perda nel percorso (magari qualche pacchetto viene droppato per qualche strana regola)?

#3

Lo strano infatti è ancora più strano, perché se confronto la dimensione dei file risultano identici (al byte). Da qualche parte ho letto che un firewall può creare problemi di questo tipo, ma non sono riuscito a trovare granché, salvo il fatto che l’upload dev’essere di tipo binario e non ascii, ma questo lo è già di default, oltra al fatto che nulla ho modificato nel frattempo. E’ capitato di avere file corrotti dopo l’upload, ma così raramente che non gli ho mai dato peso, ma ora è una cosa sistematica. :wall:

#4

Trasferisci e recupera un file di testo, vedi se è corrotto ed in cosa differisce…
Non conosco apf: se non lo usi i file si corrompono?

#5

Appena provato con un file di testo (un mio script bash) di più di 1MB. Ho effettuato l’upload con lftp (che è quello che uso da sempre) e poi l’ho riscaricato con filezilla (giusto per “mescolare” un po’ i metodi). Risultato: si apre perfettamente e confrontandolo con l’originale Meld mi dice che sono identici.

Nel frattempo avevo anche provato le varie combinazioni:

  • firewalld + apf: si corrompono
  • firewalld senza apf: si corrompono
  • no firewalld, no apf: non si corrompono
  • no firewalld, si apf: non si corrompono
#6

Quindi, in base a cosa dici che il dato si corrompe? Cosa differisce? Fatto il checksum?

#7

Perché, come riportato sopra, i file compressi (nei casi indicati), non si decomprimono e ad esempio ottengo:

[code]# tar -xzvf <file.tar.gz>
gzip: stdin: invalid compressed data–crc error

gzip: stdin: invalid compressed data–length error
tar: Child returned status 1
tar: Error is not recoverable: exiting now
[/code]

#8

Ok, che il crc del tar.gz fallisca è chiaro. Se escludi ftp dall’equazione e ti limiti ad un upload/download http?
Chiedo per questo motivo: http://mywiki.wooledge.org/FtpMustDie#And_another_thing…_easy_corruption_if_files_are_large.2Fconnection_is_poor.

#9

[quote=frafra]Ok, che il crc del tar.gz fallisca è chiaro. Se escludi ftp dall’equazione e ti limiti ad un upload/download http?
Chiedo per questo motivo: http://mywiki.wooledge.org/FtpMustDie#And_another_thing…_easy_corruption_if_files_are_large.2Fconnection_is_poor.[/quote]

Provo il più presto possibile e ti dico. Una variabile dell’equazione è però il firewall… se lo disabilito ftp e connessione non mi danno alcun problema, cioè con ftp e con quella connessione il file lo trovo poi integro 10 volte su 10… (così come per altri file).

In ogni caso sì, una prova via http può essere anziché ftp è doverosa. Ora sono in giro, appena torno a casa ci provo!

#10

Ciao frafra, molto interessante il link che hai postato. Anche se conclude dicendo che un modo per controllare il trasferimento è verificare la dimensione dei file. Ma ho già detto che corrispondono al byte.
Ho provato a fare dei caricamenti via http con uno scriptino in php. Premetto che ho meno dimestichezza in questo caso, ma non sono riuscito ad effettuarlo per il file in questione. Per altri sì, ma con file molto grandi alla fine del trasferimento il server mi dà un “Internal Server Error”.

Comunque ho fatto altre prove, alla fine delle quali ho notato che il problema della “corruzione” si ha solo per file molto grandi (almeno maggiori di 10/15MB). Altri file, compressi o no, riesco a trasferirli e decomprimerli senza problemi.

Tutto questo tornerebbe a far pensare a un problema di rete (visto anche che con altre reti internet, come dicevo all’inizio del thread, il problema non c’è). Tuttavia ribadisco il fatto che se stoppo il firewall va tutto bene! Quindi che c’entra la dimensione dei file? Che c’entra la rete? Che c’entra ftp? Lftp? Curl -T?

Sto impazzendo e per ora sto risolvendo (senza mai errori e pur usando la rete “sospetta”) con il firewall disattivato (ma, almeno, con apf su).

#11

Sempre nel link che ti ho passato, si trovano alcune informazioni aggiuntive sui firewall e ftp, nel caso sia il client sia il server abbiano il firewall (vedasi punti 3 e 4). Nello specifico:

Ipotizzo quindi che uno dei due firewall (o entrambi) stia facendo qualche magheggio strano per provar a far funzionare un sistema di trasferimento file che non è adatto a questo scenario.

#12

La cosa ulteriormente strana è che è vero, come dicevamo, che il firewall fa la differenza, ma anche che tutto questo problema vale solo per una delle due reti internet che ho. Cioè con l’altra linea va tutto bene anche col firewall del server attivato.

Quanto al link, sul client non ho nessun firewall e poi non ho capito cosa dovrei fare in realtà. E non ho configurato alcuna NAT. La linea che mi dà problemi è Linkem che da quello che so è in effetti una linea nattata, peccato però che è disattivando il mio firewall (non certo quello di Linkem) che risolvo il problema (oltre al fatto che vale solo per file compressi grandi, per gli altri no…). :gratt: :eeek: :ueee: :wall:

#13

Hai firewall da entrambe le parti, giusto? Questo può creare problemi con FTP. Non conosco bene quali magie mettano in atto i firewall per gestire le connessioni FTP, ma forse è proprio questo il problema. Inoltre bisognerebbe sapere se la corruzione avviene in upload o download.

#14

No, ho il firewall solo sul server… sul client è disabilitato.
Ho provato anche a far partire l’upload e riabilitare il firewall sul server durante l’upload. Di nuovo errore.

Poi tra il server e il client ci sarà un qualche firewall di linkem nel mezzo… ma è chiaro che, da solo o con la complicità di qualcos’altro, è il firewall sul server l’ago della bilancia. Senza di lui, tutto ok. Con lui, problema.

Nessun problema, invece, per il download.

#15

Che Linkem abbia qualche magheggio nei suoi firewall per l’FTP? Hai modo di connetterti con un’altra linea?
Riepilogando: tu hai un normalissimo client, e ti provi a connettere ad un server, via Linkem, che usa Fedora, e se attivi il firewall su quest’ultimo, la trasmissione via FTP (e solo via FTP) è corrotta, giusto?
Puoi caricare via FTP e vedere di scaricare via HTTP, così da capire se il problema sia in upload o in download? Hai modo di caricare il file via SSH e scaricarlo via FTP per capirci qualcosa in più?

#16

Sospetti sul linkem ci sono, visto che con la seconda linea (come dicevo ne ho due, sia per ridondanza, sia per distribuire il carico UP/DOWN, perché trasferisco molti dati da e per il sito) tutto questo problema non c’è.

In pratica risolvo:

  1. Usando Linkem, ma con il firewall del mio server disattivato.
  2. Usando l’altra linea, a prescindere dal firewall.

E tutto questo riguarda solo i file compressi e solo l’upload, usando l’ftp (tramite lftp oppure curl, succede con entrambi), cioè ho il file compresso che sul client mi si decomprime correttamente. Poi faccio l’upload e se decomprimo il file (ora sul server) accade la situazione dei punti 1) e/o 2).

#17

Quindi direi che quelli di Linkem hanno qualche firewall in mezzo che mal gestisce lo strano caso di FTP. Credo si verifichi attivando il tuo firewall perché ce ne sono due sul percorso (uno lato server e uno lato client di fatto) e, come spiega il link di cui stavamo parlando, sono necessari dei magheggi nel firewall per far funzionare FTP in questo caso. Se fossi in te farei un’ulteriore prova: attiva i firewall e prova sia il trasferimento in modalità attiva che in modalità passiva, se possibile.

#18

A questo punto penso anch’io che lo zampino di Linkem ci sia col discorso firewall lato server e lato “loro”. Ricordando però che riguarda solo file compressi di dimensioni oltre una certa soglia.

Ho provato il discorso modalità attiva e passiva, così:

lftp -u '<user>,<passw>' ftp.miosito.com -e "set ftp:passive-mode off;put <miofile>.tar.gz;exit"
lftp -u '<user>,<passw>' ftp.miosito.com -e "set ftp:passive-mode on;put <miofile>.tar.gz;exit"

Anche se il modo passivo dovrebbe essere quello di default, ho esplicitato entrambi nel comando. Risultato:

  1. passive-mode on: solito problema.
  2. passive-mode off: non riesco a caricare, mi dà put: Errore fatale: max-retries exceeded

Ripristinando firewalld su stop, si risolve il punto 1), come sappiamo. Il punto 2) continua a darmi lo stesso errore.

#19

Domanda: date le limitazioni di ftp e gli strani hack per farlo funzionare dietro firewall, perché non utilizzare ssh o qualcosa tipo https://minio.io/?

#20

Ehhh credo che a questo punto farò così…