Il nome utente funziona, la password funziona e il client dice di essere connesso. Poi attende all’infinito un elenco di cartelle, o il primo trasferimento di file, e nulla nelle credenziali lo spiega. FTP apre una seconda connessione per ogni elenco e ogni file, ed è quella seconda connessione a fallire. L’accesso dimostra solo che la prima conversazione funziona.

Esegui i controlli in ordine. Ognuno esclude uno strato diverso, quindi fermati al primo che produce un’anomalia.

Separa prima le due connessioni

Una connessione di controllo trasporta comandi e risposte sulla porta in ascolto del server. Una connessione dati trasporta l’elenco della directory o il corpo del file, e in modalità passiva il server sceglie il proprio endpoint e lo annuncia nella risposta PASV o EPSV. Consentire la porta 21 non dice nulla sulla raggiungibilità della porta dati, ed è esattamente per questo che un accesso riesce mentre ogni elenco va in timeout. La guida di WinSCP sulle modalità FTP illustra questa separazione e i suoi requisiti di rete.

Se il client si trova dietro la VPN, il percorso dei dati attraversa lo stesso tunnel ma non necessariamente la stessa politica.

Leggi l’indirizzo nella risposta PASV

Avvia un client dettagliato e leggi la risposta invece di indovinare. curl -v ftp://user@host/ stampa la riga PASV con l’indirizzo e la porta che il server vuole, ed è a quell’indirizzo che il client si connette dopo. Se è un indirizzo privato che non significa nulla sul lato client del tunnel, la connessione dati non va da nessuna parte mentre il canale di controllo resta sano.

Confronta quell’indirizzo con l’indirizzo che il client ha effettivamente raggiunto. La discrepanza è la risposta, e di solito proviene da NAT o da un server configurato con un indirizzo interno.

Controlla l’intervallo di porte e la politica del tunnel

I server passivi assegnano porte dati da un intervallo configurato, e quell’intervallo deve essere consentito attraverso la VPN e qualsiasi firewall sul percorso. Una politica che consente 21 e nulla più è una politica solo di accesso. Conferma l’intervallo con chi gestisce il server, poi prova una porta da quell’intervallo invece di supporre che tutto l’intervallo si comporti allo stesso modo.

I canali di controllo cifrati rendono la cosa più difficile, perché un intermediario non può più riscrivere l’indirizzo annunciato in volo.

Sapere quando EPSV o un ripiego aiutano

EPSV restituisce una porta senza un indirizzo separato, il che elimina l’errore di indirizzo sbagliato quando entrambe le estremità lo supportano. Ad alcuni client si può anche dire di ignorare l’indirizzo annunciato e riutilizzare la destinazione della connessione di controllo. Entrambi sono strumenti legittimi per una topologia specifica, non una correzione universale.

Non disattivare TLS solo per far ispezionare la sessione a un ausilio. Questo scambia un protocollo funzionante con un modello di minaccia rotto.

Conferma con un elenco e un trasferimento

Dopo il cambio di politica dell’indirizzo o della porta, apri una sessione nuova sullo stesso percorso VPN ed elenca una directory. Poi trasferisci un file piccolo, perché un elenco e un trasferimento possono seguire percorsi di codice diversi su alcuni server. Controlla il log del client per una connessione dati all’indirizzo e alla porta attesi e conferma che i byte sono arrivati.

Tieni FTP, FTPS e SFTP separati in testa mentre lo fai. Un cambio di porta passiva non è un’impostazione SFTP, e la correzione non si trasferisce tra protocolli.

Articoli correlati