Mengapa penyenaraian FTP tergantung di belakang gateway VPN yang membuat NAT

Log masuk berfungsi, PWD berfungsi, kemudian LIST tergantung sehingga klien berputus asa atau beralih ke mod data lain. Pemisahan itulah tandanya: sambungan kawalan ke port 21 sihat, manakala sambungan data dibina daripada alamat atau port yang tidak dapat dicapai oleh pihak sana. Di belakang gateway VPN yang juga membuat NAT, punca biasa ialah arahan FTP yang muatannya menyebut alamat terowong seperti 10.8.0.6. Terjemahan pengepala tidak pernah menyentuh nilai itu.

Berikut ialah dari mana nilai itu datang, dan kotak mana yang dibenarkan mengubahnya.

Yang rosak ialah muatan, bukan terowong

FTP meletakkan titik hujung data di dalam aliran kawalan. Dalam mod aktif klien menghantar PORT dengan alamat dan portnya sendiri, dan pelayan memanggil balik pasangan itu. Dalam mod pasif pelayan menjawab 227 dengan pasangan, dan klien memanggil pasangan itu sebagai gantinya.

Kedua-dua bentuk membawa pernyataan jenis yang sama: sambung ke alamat ini, pada port ini. Peranti yang hanya menulis semula pengepala IP dan TCP membiarkan pernyataan itu, jadi satu hujung terus cuba mencapai alamat yang hanya wujud di sebelah sana terowong. Sambungan data tersekat selepas sambungan kawalan sudah diisytiharkan sihat.

Tiga mod, tiga muatan

Jadual di bawah menunjukkan pihak mana yang diminta memanggil, dan apa yang boleh dilakukan oleh NAT yang hanya menulis semula pengepala mengenainya.

Baca lajur terakhir sebagai perkara yang gagal dahulu. Dalam mod aktif pelayan yang memanggil alamat peribadi; dalam mod pasif klien; dengan FTPS muatannya teks sifer dan kotak tengah ada lebih sedikit untuk diusahakan.

Letakkan pembantu di tempat terjemahan berlaku

Di Linux penulisan semula muatan dilakukan oleh pembantu nf_conntrack_ftp. Ia memerhati sambungan kawalan, mempelajari port yang dirundingkan, mencipta jangkaan untuk aliran data, dan pada kotak NAT menulis semula alamat dan port di dalam muatan. Ia hanya membantu pada peranti yang menterjemah alamat klien. Memuatkannya pada klien, atau pada penghala yang hanya meneruskan aliran, tidak mengubah apa-apa pada sesi.

Ketiga-tiga arahan ini menunjukkan sama ada modul hadir, sama ada ia dilekatkan, dan sama ada jangkaan wujud semasa sesi dibuka:

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

Memuatkan modul bukanlah sama dengan melekatkannya. Kernel dari 4.7 ke atas datang dengan net.netfilter.nf_conntrack_helper=0, jadi pembantu menunggu peraturan eksplisit, contohnya iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Jika senarai jangkaan kekal kosong semasa pemindahan dicuba, pelekatan itulah yang perlu diperiksa, bukan modul.

Mod pasif: beritahu pelayan apa yang hendak diiklankan

Mod pasif lebih mudah dijadikan deterministik kerana pelayan boleh diberitahu apa yang perlu diletakkan dalam balasan 227. Dalam vsftpd itu pasv_address, bersama pasv_min_port dan pasv_max_port; ProFTPD menggunakan MasqueradeAddress dan PassivePorts. Tetapkan itu dahulu, kerana alamat yang diiklankan dengan betul menghapuskan keperluan menulis semula apa-apa di sebelah itu.

Kemudian biarkan julat port itu tepat melalui gateway, contohnya -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, supaya peraturan sepadan dengan apa yang diiklankan pelayan.

Kedua-dua tetapan mesti bersetuju. Pelayan yang disuruh mengiklankan 30000-30100 manakala gateway membenarkan 40000-40100 gagal dengan cara paling tidak membantu: perbualan kawalan kelihatan sihat dan setiap sambungan data mati. Bandingkan nombor sebelum menyahpepijat apa-apa lagi.

Dua tanda kegagalan, dan apa yang dibuang oleh FTPS

Tergantung pada LIST menunjuk ke sambungan data pertama sesi, di mana penulisan semula alamat dan jangkaan kedua-duanya mesti berfungsi. Tergantung pada RETR selepas LIST yang berfungsi menunjuk ke pemindahan itu sendiri, iaitu julat pasif atau MTU terowong. Tanda kedua itu bukan masalah muatan, dan tetapan pembantu tidak akan membaikinya.

FTP melalui TLS membuang muatan yang dibaca oleh pembantu. Kotak tengah tidak boleh menulis semula nilai PORT atau PASV yang tidak dapat dinyahsifernya, jadi pilihan yang tinggal ialah proksi yang menamatkan TLS, pelayan yang mengiklankan alamat yang boleh dicapai dalam julat terbatas, atau protokol pemindahan lain.

Urutan pemeriksaan yang ringkas

Bekerja dari gejala ke luar. Sahkan LIST gagal manakala PWD berjaya, tangkap alamat di dalam muatan PORT atau 227, dan tanya peranti mana yang menterjemah alamat itu. Lekatkan pembantu di situ, perhatikan senarai jangkaan semasa satu pemindahan, kemudian baiki mod pasif pada pelayan dan cerminkan julat itu dalam peraturan gateway.

Asingkan kegagalan laluan data daripada kegagalan pemindahan pukal, kerana kedua-duanya membawa anda ke tetapan yang berbeza.