FTP-login werkt, maar de mapweergave blijft hangen: waarom

De gebruikersnaam werkt, het wachtwoord werkt, en de client zegt dat hij verbonden is. Dan wacht hij eindeloos op een mapweergave, of op de eerste bestandsoverdracht, en niets in de inloggegevens verklaart dat. FTP opent een tweede verbinding voor elke weergave en elk bestand, en juist die tweede verbinding faalt. De login bewijst alleen dat het eerste gesprek werkt.

Werk de controles in volgorde af. Elk sluit een andere laag uit, dus stop bij de eerste die een afwijking oplevert.

Scheid eerst de twee verbindingen

Een controleverbinding draagt opdrachten en antwoorden op de luisterpoort van de server. Een dataconnectie draagt de mapweergave of de inhoud van het bestand, en in passieve modus kiest de server zijn eindpunt en kondigt dat aan in het PASV- of EPSV-antwoord. Poort 21 toestaan zegt niets over de bereikbaarheid van de datapoort, en daarom lukt een login wel terwijl elke weergave in een time-out loopt. De gids van WinSCP over FTP-modi legt die splitsing en de netwerkvereisten uit.

Zit de client achter de VPN, dan loopt het datapad door dezelfde tunnel maar niet noodzakelijk door hetzelfde beleid.

Lees het adres in het PASV-antwoord

Start een uitgebreide client en lees het antwoord in plaats van te gokken. curl -v ftp://user@host/ drukt de PASV-regel af met het adres en de poort die de server wil, en naar dat adres maakt de client vervolgens verbinding. Is het een privéadres dat aan de clientkant van de tunnel niets betekent, dan gaat de dataconnectie nergens heen terwijl het controlekanaal gezond blijft.

Vergelijk dat adres met het adres dat de client werkelijk bereikte. De afwijking is het antwoord, en die komt meestal van NAT of van een server die met een intern adres is geconfigureerd.

Controleer het poortbereik en het tunnelbeleid

Passieve servers wijzen datapoorten toe uit een geconfigureerd bereik, en dat bereik moet via de VPN en elke firewall op de route zijn toegestaan. Een beleid dat 21 toestaat en verder niets is een beleid dat alleen voor inloggen geldt. Bevestig het bereik met degene die de server beheert, en test dan één poort eruit in plaats van aan te nemen dat het hele bereik zich hetzelfde gedraagt.

Versleutelde controlekanaalen maken dit moeilijker, omdat een tussenliggende box het aangekondigde adres niet langer onderweg kan herschrijven.

Weet wanneer EPSV of een terugvaloptie helpt

EPSV geeft een poort terug zonder apart adres, wat de fout met het verkeerde adres wegneemt wanneer beide kanten het ondersteunen. Aan sommige clients kan ook worden opgedragen het aangekondigde adres te negeren en de bestemming van de controleverbinding opnieuw te gebruiken. Beide zijn legitieme hulpmiddelen voor een specifieke topologie, geen algemene oplossing.

Schakel TLS niet uit alleen om een hulpprogramma de sessie te laten inspecteren. Dat ruilt een werkend protocol in voor een kapot dreigingsmodel.

Bevestig met een weergave en een overdracht

Open na de wijziging van het adres- of poortbeleid een nieuwe sessie over hetzelfde VPN-pad en toon een map. Draag daarna een klein bestand over, omdat een weergave en een overdracht op sommige servers verschillende codepaden kunnen volgen. Controleer in het clientlogboek op een dataconnectie naar het verwachte adres en de verwachte poort, en bevestig dat de bytes zijn aangekomen.

Houd FTP, FTPS en SFTP uit elkaar in je hoofd terwijl je dit doet. Een wijziging van de passieve poort is geen SFTP-instelling, en de oplossing gaat niet over tussen protocollen.