Waarom FTP-lysies agter ’n VPN-toegangspoort met NAT vashaak

Die aanmelding werk, PWD werk, en dan hang LIST totdat die kliënt moed opgee of na ’n ander datamodus oorskakel. Daardie skeiding is die kenmerk: die beheerverbinding na poort 21 is gesond, terwyl die dataverseinding gebou word vanaf ’n adres of poort wat die ander kant nie kan bereik nie. Agter ’n VPN-toegangspoort wat ook NAT doen, is die gewone oorsaak ’n FTP-opdrag waarvan die vrag ’n tonneladres soos 10.8.0.6 noem. Kopreël-omsetting raak nooit daardie waarde nie.

Wat volg, is waar daardie waarde vandaan kom, en watter boks dit mag verander.

Wat breek, is die vrag, nie die tonnel nie

FTP plaas die datapunt binne die beheerstroom. Aktiewe modus laat die kliënt PORT stuur met sy eie adres en poort, en die bediener skakel terug na daardie tuple. Passiewe modus laat die bediener 227 antwoord met ’n tuple, en die kliënt skakel eerder daardie een.

Albei vorme dra dieselfde soort stelling: verbind na hierdie adres, op hierdie poort. ’n Toestel wat net IP- en TCP-kopreëls herskryf, laat die stelling ongemoeid, so een kant bly probeer om ’n adres te bereik wat net aan die ander kant van ’n tonnel bestaan. Die dataverseinding staak nadat die beheerverbinding reeds as gesond verklaar is.

Drie modusse, drie vragte

Die tabel hieronder wys watter kant gevra word om te skakel, en wat ’n NAT wat net kopreëls herskryf daaraan kan doen.

Lees die laaste kolom as die ding wat eerste faal. Met aktiewe modus is dit die bediener wat na ’n private adres skakel; met passiewe modus is dit die kliënt; met FTPS is die vrag syferskrif en het die middelboks nog minder om mee te werk.

Plaas die helper waar die omsetting gebeur

Op Linux word die vrag-herskrywing deur die nf_conntrack_ftp-helper gedoen. Dit hou die beheerverbinding dop, leer die poort wat beding is, skep ’n verwagting vir die datavloei, en op ’n NAT-boks herskryf dit die adres en poort binne die vrag. Dit help net op die toestel wat die kliëntadres omstel. Om dit op die kliënt te laai, of op ’n roeteerder wat net die vloei aanstuur, verander niks aan die sessie nie.

Hierdie drie opdragte wys of die module teenwoordig is, of dit aangeheg is, en of daar ’n verwagting bestaan terwyl ’n sessie oop is:

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

Om die module te laai is nie dieselfde as om dit aan te heg nie. Kerne vanaf 4.7 word met net.netfilter.nf_conntrack_helper=0 verskeep, so die helper wag op ’n eksplisiete reël, byvoorbeeld iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. As die verwagtingslys leeg bly terwyl ’n oordrag probeer word, is die aanhegting wat om na te kyk, nie die module nie.

Passiewe modus: sê vir die bediener wat om te adverteer

Passiewe modus is makliker om deterministies te maak omdat die bediener gesê kan word wat om in die 227-antwoord te sit. In vsftpd is dit pasv_address, saam met pasv_min_port en pasv_max_port; ProFTPD gebruik MasqueradeAddress en PassivePorts. Stel dié eerste, want ’n korrekte geadverteerde adres verwyder die noodsaak om enigiets aan daardie kant te herskryf.

Laat dan presies daardie poortreeks deur die toegangspoort, byvoorbeeld -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, sodat die reël ooreenstem met wat die bediener adverteer.

Die twee instellings moet ooreenstem. ’n Bediener wat gesê word om 30000-30100 te adverteer terwyl die toegangspoort 40000-40100 toelaat, faal op die mins nuttige manier: die beheergesprek lyk gesond en elke dataverseinding sterf. Vergelyk die syfers voordat jy enigiets anders ontfout.

Twee foutmerke, en wat FTPS verwyder

’n Hang op LIST wys na die eerste dataverseinding van die sessie, waar adres-herskrywing en die verwagting albei moet werk. ’n Hang op RETR na ’n werkende LIST wys na die oordrag self, wat die passiewe reeks of die tonnel-MTU beteken. Daardie tweede merkteken is nie ’n vragprobleem nie, en helper-instellings sal dit nie regmaak nie.

FTP oor TLS verwyder die vrag wat die helper lees. ’n Middelboks kan nie ’n PORT- of PASV-waarde herskryf wat dit nie kan ontsyfer nie, so die oorblywende keuses is ’n instaanbediener wat TLS beëindig, ’n bediener wat ’n bereikbare adres binne ’n begrensde reeks adverteer, of ’n ander oordragprotokol.

’n Kort volgorde van kontroles

Werk van die simptoom uit na buite. Bevestig dat LIST faal terwyl PWD slaag, vang die adres binne die PORT- of 227-vrag vas, en vra watter toestel daardie adres omstel. Heg die helper daar aan, hou die verwagtingslys dop tydens een oordrag, maak dan passiewe modus op die bediener reg en spieël die reeks in die toegangspoort-reël.

Hou die datapad-fout apart van die groot-oordrag-fout, want hulle stuur jou na verskillende instellings.