Mengapa daftar FTP menggantung di belakang gateway VPN yang menjalankan NAT

Login berhasil, PWD berhasil, lalu LIST menggantung sampai klien menyerah atau beralih ke mode data lain. Pemisahan itulah tanda khasnya: koneksi kontrol ke port 21 sehat, sedangkan koneksi data dibangun dari alamat atau port yang tidak bisa dijangkau sisi lain. Di belakang gateway VPN yang juga menjalankan NAT, tersangka yang biasa adalah perintah FTP yang payload-nya menyebut alamat terowongan seperti 10.8.0.6. Terjemahan header tidak pernah menyentuh nilai itu.

Berikut ini adalah dari mana nilai itu berasal, dan kotak mana yang boleh mengubahnya.

Yang rusak adalah payload, bukan terowongannya

FTP menaruh titik ujung data di dalam aliran kontrol. Pada mode aktif klien mengirim PORT dengan alamat dan portnya sendiri, dan server menelepon balik ke pasangan itu. Pada mode pasif server menjawab 227 dengan sebuah pasangan, dan klien menelepon pasangan itu sebagai gantinya.

Kedua bentuk membawa pernyataan yang sama jenisnya: sambungkan ke alamat ini, pada port ini. Perangkat yang hanya menulis ulang header IP dan TCP membiarkan pernyataan itu apa adanya, sehingga satu ujung terus berusaha menjangkau alamat yang hanya ada di sisi lain terowongan. Koneksi data macet setelah koneksi kontrol sudah dinyatakan sehat.

Tiga mode, tiga payload

Tabel di bawah menunjukkan sisi mana yang diminta menelepon, dan apa yang bisa dilakukan NAT yang hanya menulis ulang header atas hal itu.

Baca kolom terakhir sebagai hal yang gagal lebih dulu. Pada mode aktif serverlah yang menelepon alamat privat; pada mode pasif klien; dengan FTPS payload-nya teks tersandi dan kotak perantara punya lebih sedikit lagi untuk dikerjakan.

Letakkan helper di tempat penerjemahan terjadi

Di Linux penulisan ulang payload dilakukan oleh helper nf_conntrack_ftp. Ia mengawasi koneksi kontrol, mempelajari port yang dinegosiasikan, membuat harapan untuk aliran data, dan pada kotak NAT menulis ulang alamat serta port di dalam payload. Ia hanya membantu pada perangkat yang menerjemahkan alamat klien. Memuatnya di klien, atau di router yang hanya meneruskan aliran, tidak mengubah apa pun pada sesi.

Ketiga perintah ini menunjukkan apakah modulnya ada, apakah terpasang, dan apakah ada harapan saat sesi terbuka:

modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftp

Memuat modul tidak sama dengan memasangnya. Kernel sejak 4.7 dikirim dengan net.netfilter.nf_conntrack_helper=0, jadi helper menunggu aturan eksplisit, misalnya iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Jika daftar harapan tetap kosong saat transfer dicoba, pemasangan itulah yang perlu diperiksa, bukan modulnya.

Mode pasif: beri tahu server apa yang harus diiklankan

Mode pasif lebih mudah dibuat deterministik karena server bisa diberi tahu apa yang harus ditaruh di balasan 227. Di vsftpd itu pasv_address, bersama pasv_min_port dan pasv_max_port; ProFTPD memakai MasqueradeAddress dan PassivePorts. Atur itu lebih dulu, karena alamat yang diiklankan dengan benar menghapus kebutuhan menulis ulang apa pun di sisi itu.

Lalu izinkan tepat rentang port itu melewati gateway, misalnya -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, agar aturannya cocok dengan yang diiklankan server.

Kedua pengaturan harus sepakat. Server yang diminta mengiklankan 30000-30100 sementara gateway mengizinkan 40000-40100 gagal dengan cara paling tidak menolong: percakapan kontrol tampak sehat dan setiap koneksi data mati. Bandingkan angkanya sebelum menelusuri hal lain.

Dua tanda kegagalan, dan apa yang dihapus FTPS

Menggantung pada LIST menunjuk ke koneksi data pertama sesi, tempat penulisan ulang alamat dan harapan keduanya harus bekerja. Menggantung pada RETR setelah LIST yang berhasil menunjuk ke transfer itu sendiri, artinya rentang pasif atau MTU terowongan. Tanda kedua itu bukan masalah payload, dan pengaturan helper tidak akan memperbaikinya.

FTP di atas TLS menghapus payload yang dibaca helper. Kotak perantara tidak bisa menulis ulang nilai PORT atau PASV yang tidak bisa didekripsinya, jadi pilihan yang tersisa adalah proksi yang mengakhiri TLS, server yang mengiklankan alamat terjangkau dalam rentang terbatas, atau protokol transfer lain.

Urutan pemeriksaan yang singkat

Bekerjalah dari gejala ke luar. Pastikan LIST gagal sementara PWD berhasil, tangkap alamat di dalam payload PORT atau 227, dan tanyakan perangkat mana yang menerjemahkan alamat itu. Pasang helper di sana, amati daftar harapan selama satu transfer, lalu perbaiki mode pasif di server dan cerminkan rentangnya di aturan gateway.

Pisahkan kegagalan jalur data dari kegagalan transfer massal, karena keduanya mengarahkan Anda ke pengaturan berbeda.