Selamat pagi semuanya,
Saya hosting server FileZilla FTP (mode pasif) pada server WIN 2012 R2 yang di-host di MS Azure.
Transfer FTP umumnya berfungsi dengan baik - Beberapa unggahan dan pengambilan FTP berjalan setiap hari.
Saya telah membuka sejumlah besar port (titik akhir) relatif pada Azure Portal / sisi untuk memungkinkan mode pasif.
Secara sporadis (rata-rata setiap 2 hari sekali) Saya melihat masalah transfer FTP seperti berikut:
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 (tim.kosse@filezilla-project.org)
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
Seperti disebutkan, ada beberapa transfer FTP yang dilakukan setiap hari (otomatis) dan menyapu lebih dari 140 port yang ditugaskan untuk server FTP FileZilla (bertindak dalam mode pasif).
Saya memiliki tangkapan Wireshark yang berjalan di VM yang dihosting di Azure; Saya dapat melihat dari Wireshark menangkap bahwa peristiwa "426 koneksi ditutup" sebenarnya dicocokkan oleh RST yang bersumber dari VM di Azure dan dikirim kembali ke klien yang mengeluarkan perintah PASV (yaitu dalam contoh di atas, server FTP membalas ke perintah klien PASV dengan port: 234.235 -> 60139; klien mencoba untuk membuka saluran data ke port 60139 untuk memulai transfer -> server FTP membalas segera (dalam MS sesuai dengan tangkapan Wireshark) mengeluarkan RST ke klien).
Saya memikirkan beberapa masalah alokasi port fana di sisi server FTP -> jadi saya mengurangi rentang port ephemeral OS dinamis yang diizinkan untuk tidak tumpang tindih dengan kisaran port pasif FTP - menggunakan
netsh int ipv4 set dynamicport tcp start=49152 num=10000
juga, saya secara eksplisit menambahkan reservasi kisaran port ke stack netsh melalui perintah
netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent
Meski begitu, masalahnya masih kadang terjadi.
Saya membaca diskusi teknis yang luas di situs web ini dan juga pada sesi teknik MS Azure tentang bagaimana Azure memonitor status titik akhir (ketika bagian dari set LB) tetapi ini tidak berlaku dalam kasus saya sebagai transfer Pasif FTP (pengambilan dan unggahan) pada port acak dalam kisaran port pasif FTP khusus umumnya berfungsi dengan baik.
Saya dapat memberikan rincian tambahan jika diperlukan - sementara itu, saya akan berterima kasih atas saran tambahan untuk pemecahan masalah / penyelidikan di sisi server dan klien (cukup yakin masalahnya bukan terkait konfigurasi jaringan atau jaringan).
Saya juga ingin meminta saran / kiat pemecahan masalah / penyelidikan tambahan tentang cara debug winock untuk masalah ketersediaan soket sisi server.
426
kesalahan aborsi selalu mengikuti beberapa detik di belakang sesi lain mendapatkan 550
izin ditolak kesalahan. Saya curiga ini adalah bug pada FileZilla, tetapi bagi kami perbaikannya adalah mencegah 550 (dalam kasus kami, sistem pengujian berusaha mengakses folder pengujian, tetapi menggunakan kredensial produksi; jadi kami hanya harus memperbaiki kredensial sistem itu) .