Buongiorno a tutti,
Sto ospitando un server FTP FileZilla (modalità passiva) su un server WIN 2012 R2 ospitato in MS Azure.
I trasferimenti FTP funzionano generalmente bene - Diversi caricamenti e recuperi FTP vengono eseguiti su base giornaliera.
Ho aperto una vasta gamma di porte (endpoint) relativamente sul portale / lato di Azure per consentire la modalità passiva.
Sporadicamente (in media una volta ogni 2 giorni) vedo problemi di trasferimento FTP come il seguente:
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file1
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file2
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file3
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071050
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> CWD dev_updates/Infrastructure/folder
8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 250 CWD successful. "dev_updates/Infrastructure/folder" is current directory.
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> PASV
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 227 Entering Passive Mode (104,40,Y,X,234,235)
8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 426 Connection closed; aborted transfer of ""
8/8/2016 9:10:01 AM - USER_FILEZILLA (62.154.Y.X)> disconnected.
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> Connected on port 21, sending welcome message...
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-FileZilla Server 0.9.57 beta
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220 Please visit https://filezilla-project.org/
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> USER USER_FILEZILLA
8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 331 Password required for
Come accennato, ci sono diversi trasferimenti FTP che avvengono su base giornaliera (automatizzata) e spaziano sull'intervallo di oltre 140 porte assegnato al server FTP FileZilla (che agisce in modalità passiva).
Ho un'acquisizione di Wireshark in esecuzione sulla macchina virtuale ospitata in Azure; Vedo dalle acquisizioni di Wireshark che gli eventi "426 connessione chiusa" sono effettivamente abbinati da un RST proveniente dalla VM in Azure e rispedito al client che ha emesso il comando PASV (ovvero nell'esempio sopra, il server FTP risponde a il comando PASV client con la porta: 234.235 -> 60139; il client tenta di aprire un canale dati alla porta 60139 per avviare il trasferimento -> il server FTP risponde immediatamente (all'interno di MS secondo l'acquisizione di Wireshark) emettendo un RST al cliente).
Ho pensato ad alcuni problemi di allocazione delle porte effimere sul lato server FTP -> quindi ho ridotto l'intervallo di porte effimere del sistema operativo dinamico consentito per non sovrapporre l'intervallo di porte passive FTP - usando
netsh int ipv4 set dynamicport tcp start=49152 num=10000
inoltre, ho aggiunto esplicitamente la prenotazione dell'intervallo di porte allo stack netsh tramite il comando
netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent
Tuttavia, il problema si verifica ancora occasionalmente.
Ho letto le discussioni tecniche approfondite su questo sito Web e sulla sessione di technet di MS Azure su come Azure monitora lo stato degli endpoint (quando parte di un set LB) ma questo non è applicabile nel mio caso come trasferimenti passivi FTP (recupero e upload) su porte casuali all'interno dell'intervallo di porte passive FTP riservate funzionano generalmente bene.
Posso fornire ulteriori dettagli se necessario - nel frattempo, sarei grato per ulteriori suggerimenti sulla risoluzione dei problemi / indagini sul lato server e client (praticamente certo che il problema non è relativo alla rete o alla configurazione di rete).
Vorrei anche chiedere ulteriori suggerimenti / suggerimenti per la risoluzione di problemi / indagini su come eseguire il debug winsock per possibili problemi di disponibilità dei socket lato server.
426
errore di aborto seguiva sempre un paio di secondi dietro un'altra sessione ottenendo un 550
errore negato l'autorizzazione. Ho il sospetto che questo sia un bug con FileZilla, ma per noi la correzione era prevenire il 550 (nel nostro caso, un sistema di test stava tentando di accedere alla cartella di test, ma usando le credenziali di produzione; quindi abbiamo semplicemente dovuto correggere le credenziali di quel sistema) .