Přihlášení k FTP funguje, ale výpis složky zamrzne: proč

Uživatelské jméno funguje, heslo funguje a klient tvrdí, že je připojen. Pak navěky čeká na výpis složky nebo na první přenos souboru a nic v přihlašovacích údajích to nevysvětluje. FTP otevírá druhé spojení pro každý výpis a každý soubor a právě toto druhé spojení selhává. Přihlášení jen dokazuje, že první rozhovor funguje.

Proveďte kontroly popořadě. Každá vylučuje jinou vrstvu, takže zastavte u první, která vykáže anomálii.

Nejprve oddělte obě spojení

Řídicí spojení přenáší příkazy a odpovědi na naslouchajícím portu serveru. Datové spojení přenáší výpis adresáře nebo tělo souboru a v pasivním režimu server volí svůj koncový bod a oznamuje ho v odpovědi PASV nebo EPSV. Povolení portu 21 nic neříká o tom, zda je datový port dostupný, a právě proto se přihlášení podaří, zatímco každý výpis vyprší. Průvodce WinSCP režimy FTP vysvětluje toto rozdělení a jeho síťové požadavky.

Pokud klient sedí za VPN, datová cesta prochází stejným tunelem, ale ne nutně stejnou politikou.

Přečtěte adresu v odpovědi PASV

Spusťte podrobný klient a přečtěte odpověď, místo abyste hádali. curl -v ftp://user@host/ vypíše řádek PASV s adresou a portem, které server chce, a právě na tuto adresu se klient následně připojuje. Pokud jde o soukromou adresu, která na klientské straně tunelu nic neznamená, datové spojení nikam nevede, zatímco řídicí kanál zůstává zdravý.

Porovnejte tuto adresu s adresou, na kterou se klient skutečně dostal. Nesoulad je odpověď a obvykle pochází z NAT nebo ze serveru nakonfigurovaného s interní adresou.

Zkontrolujte rozsah portů a politiku tunelu

Pasivní servery přidělují datové porty z nakonfigurovaného rozsahu a tento rozsah musí být povolen přes VPN a jakýkoli firewall na cestě. Politika, která povoluje 21 a nic jiného, je politikou jen pro přihlášení. Potvrďte rozsah u toho, kdo server provozuje, a pak otestujte jeden port z něj, místo abyste předpokládali, že se celý rozsah chová stejně.

Šifrované řídicí kanály to ztěžují, protože prostředník už nemůže přepsat oznámenou adresu za letu.

Vězte, kdy pomůže EPSV nebo záložní varianta

EPSV vrací port bez samostatné adresy, což odstraňuje selhání kvůli špatné adrese, když ho podporují oba konce. Některým klientům lze také nařídit ignorovat oznámenou adresu a znovu použít cíl řídicího spojení. Obojí jsou legitimní nástroje pro konkrétní topologii, ne univerzální řešení.

Nevypínejte TLS jen proto, aby pomocník prohlédl relaci. To vyměňuje fungující protokol za rozbitý model hrozeb.

Potvrďte výpisem a přenosem

Po změně politiky adresy nebo portů otevřete novou relaci po stejné cestě VPN a vypište adresář. Pak přeneste malý soubor, protože výpis a přenos mohou na některých serverech jít různými cestami kódu. Zkontrolujte v logu klienta datové spojení na očekávanou adresu a port a potvrďte, že bajty dorazily.

Mějte při tom FTP, FTPS a SFTP oddělené v hlavě. Změna pasivního portu není nastavení SFTP a oprava se mezi protokoly nepřenáší.