Dopo aver cambiato operatore e di conseguenza aver sostituito il modem/router a causa dell’implementazione della VDSL ho dovuto combattere diverse ore con un app che utilizzavo su smartphone (FTP Manager) che non voleva più collegarsi correttamente al mio server FTP casalingo.
Tengo a precisare che a causa dell’indirizzo IP pubblico dinamico ho sempre utilizzato un DDNS, che non è cambiato.
Tale server aveva sempre lavorato sulla porta standard ma con un port forwarding su una porta non standard verso l’esterno per ragioni di sicurezza.
Sul nuovo router avevo esattamente aperto la relativa porta allo stesso modo, ma non ne voleva sapere di funzionare, n’è da un client FTP esterno, n’è dall’app.
Dopo averci sbattuto il muso diverse ore e dopo diverse prove sono giunto alla conclusione che:
- il server FTP viene raggiunto soltanto se il port forwarding lavora unicamente sulla porta 21 (in questo caso non è necessario aprire le porte PASV indicate al punto successivo)
- Per avere accesso dall’esterno su una porta non standard ha bisogno in questo caso di aprire anche le porte 55536-55547 necessarie per l’uso della modalità PASV.
- Filezilla client segnala il seguente errore: “Il server ha inviato una risposta passiva contenente un indirizzo non raggiungibile. Sarà usato l’indirizzo del server” esso però riesce ugualmente a connettersi anche con questo errore. ma purtroppo non l’app su smartphone che non vorrei sostituire con un altra, anche se ho notato che utilizzando altre app il problema e’ comunque presente.
- Impostando una DMZ sul mio server FTP il problema dell’app non si risolve, questo significa che NON è un problema di firewall o di mal configurazione.
Dopo qualche ricerca quà e là su internet, sono riuscito a capire che il problema potrebbe dipendere dal fatto che il modem attuale ha attivo il NAT Loopback, ovvero una regola predefinita dell’iptables per far “uscire” su internet tutta la vostra rete locale con un unico IP pubblico, e si occupa anche del corretto inoltro delle porte.
Finché un pacchetto destinato all’IP pubblico arriva dall’esterno non ci sono problemi ed inoltra il traffico all’host locale designato per ascoltare su quella particolare porta.
Quando il pacchetto viene generato dall’interno invece, esso arriva al router che in mancanza della regola di loopback può comportarsi in due modi diversi, dipendenti dai firmware del produttore del router:
- Segnala il pacchetto un tentativo di spoof e lo scarta
- Inoltra alla sua WAN, avente IP pubblico se sulla porta in ascolto è presente un demone, esso risponde, altrimenti la connessione va in timeout.
In entrambi i casi non abbiamo ottenuto il risultato sperato perchè anche se nel secondo caso otteniamo una risposta, essa arriva da un server che non è quello che ci interessava.
La cosa strana che ancora non sono riuscito a spiegarmi è come Filezilla riesce ugualmente a caricare il contenuto dell’FTP mostrando l’errore (l’ipotesi è che abbia qualche configurazione interna differente e che permette il recupero del giusto indirizzo ip dall’esterno.)
Per risolvere questo problema occorre abilitare sul server FTP l’opzione “pasv_addr_resolve = yes” e “pasv_address = il vostroippubblico o DDNS” che inoltra ai dispositivi esterni il corretto IP pubblico.
Nel caso del mio server FTP basato su Synology è necessario spuntare l’opzione “riporta l’IP esterno in modalità PASV” e “Assegna IP Esterno: Default External IP”, cosi facendo risponde con il DDNS appena richiamato dal client.
In questo modo l’app su smartphone ritorna a funzionare regolarmente.
Infine, per comodità e dopo averne capito il corretto instradamento, ho optato per l’attivazione di SFTP anzichè di FTP, più sicuro, e al tempo stesso mi evita di tenere aperto il range di porte 55536-55547 e di conseguenza tutte le operazioni di routing descritte sopra.