Nazwa użytkownika działa, hasło działa, a klient twierdzi, że jest połączony. Potem czeka w nieskończoność na listę katalogu albo na pierwsze przesłanie pliku, i nic w danych logowania tego nie wyjaśnia. FTP otwiera drugie połączenie dla każdej listy i każdego pliku, i to właśnie to drugie połączenie zawodzi. Logowanie dowodzi tylko, że pierwsza rozmowa działa.

Wykonuj kontrole po kolei. Każda wyklucza inną warstwę, więc zatrzymaj się na pierwszej, która da anomalię.

Najpierw rozdziel dwa połączenia

Połączenie sterujące przenosi polecenia i odpowiedzi na porcie nasłuchu serwera. Połączenie danych przenosi listę katalogu lub treść pliku, a w trybie pasywnym serwer wybiera swój punkt końcowy i ogłasza go w odpowiedzi PASV lub EPSV. Zezwolenie na port 21 nic nie mówi o tym, czy port danych jest osiągalny, i właśnie dlatego logowanie się udaje, a każda lista kończy się przekroczeniem czasu. Przewodnik WinSCP poświęcony trybom FTP wyjaśnia ten podział i jego wymagania sieciowe.

Jeśli klient znajduje się za VPN, ścieżka danych przechodzi przez ten sam tunel, ale niekoniecznie przez te same zasady.

Odczytaj adres w odpowiedzi PASV

Uruchom szczegółowego klienta i odczytaj odpowiedź zamiast zgadywać. curl -v ftp://user@host/ wypisuje wiersz PASV z adresem i portem, których chce serwer, i to na ten adres klient łączy się następnie. Jeśli to adres prywatny, który nic nie znaczy po stronie klienta w tunelu, połączenie danych donikąd nie prowadzi, podczas gdy kanał sterujący pozostaje zdrowy.

Porównaj ten adres z adresem, do którego klient faktycznie dotarł. Rozbieżność jest odpowiedzią i zwykle pochodzi z NAT lub z serwera skonfigurowanego z adresem wewnętrznym.

Sprawdź zakres portów i zasady tunelu

Serwery pasywne przydzielają porty danych ze skonfigurowanego zakresu, a ten zakres musi być dozwolony przez VPN i każdą zaporę na ścieżce. Zasady, które zezwalają na 21 i nic więcej, to zasady tylko do logowania. Potwierdź zakres u osoby zarządzającej serwerem, a następnie przetestuj jeden port z niego, zamiast zakładać, że cały zakres zachowuje się tak samo.

Szyfrowane kanały sterujące utrudniają to, ponieważ pośredniczące urządzenie nie może już przepisać ogłoszonego adresu w locie.

Wiedz, kiedy pomaga EPSV lub wariant zapasowy

EPSV zwraca port bez osobnego adresu, co usuwa błąd błędnego adresu, gdy obsługują go oba końce. Niektórym klientom można też kazać ignorować ogłoszony adres i użyć ponownie celu połączenia sterującego. Oba są legalnymi narzędziami dla konkretnej topologii, a nie uniwersalnym rozwiązaniem.

Nie wyłączaj TLS tylko po to, by narzędzie pomocnicze sprawdziło sesję. To zamienia działający protokół na zepsuty model zagrożeń.

Potwierdź listą i transferem

Po zmianie zasad adresu lub portu otwórz nową sesję tą samą ścieżką VPN i wylistuj katalog. Następnie prześlij mały plik, ponieważ lista i transfer mogą na niektórych serwerach iść różnymi ścieżkami kodu. Sprawdź w dzienniku klienta połączenie danych z oczekiwanym adresem i portem i potwierdź, że bajty dotarły.

Trzymaj FTP, FTPS i SFTP osobno w głowie, wykonując te czynności. Zmiana portu pasywnego nie jest ustawieniem SFTP, a poprawka nie przenosi się między protokołami.

Powiązane artykuły