Tryb pasywny FTP (Filezilla) Windows Server 2012 okazjonalnie „426 Połączenie zamknięte; przerwane przeniesienie „”

9

Dzień dobry wszystkim,

Hostuję serwer FTP FileZilla (tryb pasywny) na serwerze WIN 2012 R2 hostowanym na MS Azure.

Transfer FTP działa ogólnie dobrze - codziennie odbywa się kilka operacji przesyłania i pobierania FTP.

Otworzyłem względnie duży zakres portów (punktów końcowych) na portalu Azure / stronie, aby umożliwić tryb pasywny.

Sporadycznie (średnio raz na 2 dni) występują problemy z transferem FTP, takie jak:

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 ([email protected])

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 

Jak wspomniano, kilka codziennych (automatycznych) transferów FTP odbywa się w szerokim zakresie portów ponad 140 przypisanych do serwera FTP FileZilla (działającego w trybie pasywnym).

Mam przechwytywanie Wireshark uruchomione na maszynie wirtualnej hostowanej na platformie Azure; Widzę, że Wireshark przechwytuje, że zdarzenia „426 zamknięte połączenie” są w rzeczywistości dopasowane przez RST pozyskane przez maszynę wirtualną na platformie Azure i wysłane z powrotem do klienta, który wydał polecenie PASV (tj. W powyższym przykładzie serwer FTP odpowiada na polecenie PASV klienta z portem: 232435 -> 60139; klient próbuje otworzyć kanał danych do portu 60139 w celu rozpoczęcia transferu -> serwer FTP odpowiada natychmiast (w MS zgodnie z przechwytywaniem Wireshark) wydając RST do klienta).

Pomyślałem o pewnym problemie z alokacją portów efemerycznych po stronie serwera FTP -> więc zmniejszyłem dozwolony zakres portów efemerycznych dynamicznego systemu operacyjnego, aby nie nakładał się na pasywny zakres portów FTP - używając

netsh int ipv4 set dynamicport tcp start=49152 num=10000

Ponadto jawnie dodałem rezerwację zakresu portów do stosu netsh za pomocą polecenia

netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent

Mimo to problem wciąż się zdarza.

Czytam obszerne dyskusje techniczne na tej stronie internetowej, a także na sesji MSNET technet na temat tego, jak Azure monitoruje stan punktów końcowych (gdy jest częścią zestawu LB), ale nie ma to zastosowania w moim przypadku jako pasywne transfery FTP (pobieranie i przesyłanie) na losowych portach w zarezerwowanym zakresie pasywnych portów FTP na ogół działają dobrze.

W razie potrzeby mogę podać dodatkowe szczegóły - w międzyczasie będę wdzięczny za dodatkowe sugestie dotyczące rozwiązywania problemów / dochodzeń po stronie serwera i klienta (prawie pewne, że problem nie jest związany z siecią lub konfiguracją sieci).

Chciałbym również poprosić o dodatkowe wskazówki / porady dotyczące rozwiązywania problemów / dochodzenia dotyczące sposobu debugowania winsock pod kątem możliwych problemów z dostępnością gniazd po stronie serwera.

Ottootto
źródło
Dodaję to jako komentarz, ponieważ tak naprawdę nie sądzę, że to odpowiedź, ale czy skonfigurowałeś TLS / SFTP na serwerze FileZilla? Miałem to samo na platformie Azure za pomocą FileZilla (dlatego znalazłem twoje pytanie). Próbując zlokalizować problem, ostatecznie wyłączyłem TLS. Dla mnie to rozwiązało problem z połączeniem. Miałem dokładnie takie zachowanie, jakie miałeś, czasem połączenie po prostu się zrywa (często po „wejściu w tryb pasywny”). Muszę jednak znaleźć przyczynę tego :(.
Roet,
Sprawdź także, czy port wymieniony w poleceniu PASV jest taki sam zarówno na kliencie, jak i na serwerze - miałem tam niedopasowania z powodu ustawienia FileZilla w odniesieniu do zewnętrznych ustawień IP. Miałem go w trybie rozstrzygania zamiast w trybie „domyślnym”.
Roet,
1
FYI: Widziałem ten sam problem. Przeglądając dzienniki, zauważyłem, że 426błąd aborcji zawsze następował kilka sekund za kolejną sesją, otrzymując 550błąd odmowy uprawnień. Podejrzewam, że jest to błąd związany z FileZilla, ale dla nas poprawka polegała na zapobieganiu 550 (w naszym przypadku system testowy próbował uzyskać dostęp do folderu testowego, ale przy użyciu poświadczeń produkcyjnych; więc po prostu musieliśmy poprawić poświadczenia tego systemu) .
JohnLBevan