Wêrom FTP-listings hingje efter in VPN-poarte dy’t NAT docht
Oanmelde en PWD slagje, wylst LIST en RETR fêstrinne as NAT allinnich kopteksten oerskriuwt. Sjoch wêr’t de FTP-helper sitte moat en hoe’t jo de passive modus reparearje.
It oanmelden wurket, PWD wurket, en dan hinget LIST oant de klant it opjout of oergeet nei in oare datamodus. Dy skieding is de sinjatuer: de kontrôleferbining nei poarte 21 is sûn, wylst de dataferbining boud wurdt fanút in adres of poarte dy’t de oare kant net berikke kin. Efter in VPN-poarte dy’t ek NAT docht, is de gewoane skuldige in FTP-opdracht wêrfan’t de lading in tunneladres lykas 10.8.0.6 neamt. Koptekstoersetting rekket dy wearde nea.
Wat folget is wêr’t dy wearde wei komt, en hokker kast it feroarje mei.
Wat brekt is de lading, net de tunnel
FTP set it datapunt binnen de kontrôle-stream. Yn aktive modus stjoert de klant PORT mei syn eigen adres en poarte, en de tsjinner skillet werom nei dat pear. Yn passive modus antwurdet de tsjinner 227 mei in pear, en de klant skillet dat ynstee.
Beide foarmen drage deselde soarte bewearing: ferbinje mei dit adres, op dizze poarte. In apparaat dat allinnich IP- en TCP-kopteksten oerskriuwt lit de bewearing gewurde, sadat ien ein by trochgiet om in adres te berikken dat allinnich oan ’e oare kant fan in tunnel bestiet. De dataferbining rint fêst neidat de kontrôleferbining al sûn ferklearre is.
Trije modi, trije ladings
De tabel hjirûnder lit sjen hokker kant frege wurdt te skiljen, en wat in NAT dy’t allinnich kopteksten oerskriuwt dêroan dwaan kin.
Lês de lêste kolom as it ding dat earst mislearret. Yn aktive modus is it de tsjinner dy’t in privee-adres skilpt; yn passive modus is it de klant; by FTPS is de lading siferskrift en hat de tuskenkast noch minder om mei te wurkjen.
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
Set de helper dêr’t de oersetting bart
Op Linux docht de helper nf_conntrack_ftp it oerskriuwen fan ’e lading. Hy hâldt de kontrôleferbining yn ’e gaten, leart de poarte dy’t ûnderhannele is, makket in ferwachting foar de datastream en skriuwt op in NAT-kast it adres en de poarte yn ’e lading oer. Hy helpt allinnich op it apparaat dat it adres fan ’e klant oerset. It op ’e klant laden, of op in router dy’t de stream allinnich trochjout, feroaret neat oan ’e sesje.
Dizze trije opdrachten litte sjen oft de module oanwêzich is, oft er oanhongen is en oft der in ferwachting bestiet wylst in sesje iepen is:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpDe module laden is net itselde as him oanhingsje. Kearnen fan 4.7 ôf komme mei net.netfilter.nf_conntrack_helper=0, dus de helper wachtet op in útdruklike regel, bygelyks iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. At de ferwachtingslist leech bliuwt wylst in oerdracht besocht wurdt, is de oanhinging wat te kontrolearjen, net de module.
Passive modus: sis de tsjinner wat er oankundigje moat
Passive modus is makliker deterministysk te meitsjen om’t de tsjinner sein wurde kin wat er yn it 227-antwurd sette moat. Yn vsftpd is dat pasv_address, tegearre mei pasv_min_port en pasv_max_port; ProFTPD brûkt MasqueradeAddress en PassivePorts. Set dy earst, om’t in krekt oankundige adres de needsaak fuorthellet om oan dy kant wat dan ek oer te skriuwen.
Lit dan krekt dat poarteberik troch de poarte, bygelyks -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, sadat de regel oerienkomt mei wat de tsjinner oankundiget.
De twa ynstellings moatte oerienkomme. In tsjinner dy’t sein wurdt 30000-30100 oan te kundigjen wylst de poarte 40000-40100 talit, mislearret op ’e minst handige manier: it kontrôlepetear liket sûn en elke dataferbining stjert. Fergelykje de sifers foardat jo wat oars debugge.
Twa flater-sinjatueren, en wat FTPS fuorthellet
In hingjen op LIST wiist nei de earste dataferbining fan ’e sesje, dêr’t sawol adresoerskriuwing as de ferwachting wurkje moat. In hingjen op RETR nei in wurkjende LIST wiist nei de oerdracht sels, dus it passive berik of de MTU fan ’e tunnel. Dy twadde sinjatuer is gjin ladingsprobleem, en helper-ynstellings reparearje it net.
FTP oer TLS hellet de lading fuort dy’t de helper lêst. In tuskenkast kin in PORT- of PASV-wearde net oerskriuwe dy’t er net ûntsiferje kin, dus de oerbliuwende karren binne in proxy dy’t TLS beëiniget, in tsjinner dy’t in berikbere adres binnen in beheind berik oankundiget, of in oar oerdrachtsprotokol.
In koarte folchoarder fan kontrôles
Wurkje fan it symptoom nei bûten. Befêstigje dat LIST mislearret wylst PWD slagget, fang it adres yn ’e PORT- of 227-lading, en freegje hokker apparaat dat adres oerset. Hingje dêr de helper oan, hâld de ferwachtingslist yn ’e gaten by ien oerdracht, reparearje dan passive modus op ’e tsjinner en spegele it berik yn ’e poarteregel.
Hâld de flater yn it datapaad apart fan ’e flater by bulk-oerdracht, om’t se jo nei ferskate ynstellings stjoere.