Kial FTP-listoj haltas malantaŭ VPN-enirejo, kiu faras NAT
Ensaluto kaj PWD sukcesas, dum LIST kaj RETR haltas, kiam NAT reskribas nur kapliniojn. Vidu, kie la FTP-helpeto devas sidi, kaj kiel ripari la pasivan reĝimon.
La ensaluto funkcias, PWD funkcias, kaj poste LIST haltas ĝis la kliento rezignas aŭ transiras al alia datuma reĝimo. Tiu disiĝo estas la signo: la rega konekto al pordo 21 estas sana, dum la datuma konekto konstruiĝas el adreso aŭ pordo, kiun la alia flanko ne povas atingi. Malantaŭ VPN-enirejo, kiu ankaŭ faras NAT, la kutima kaŭzo estas FTP-ordono, kies ŝarĝo nomas tunelan adreson kiel 10.8.0.6. Traduko de kaplinioj neniam tuŝas tiun valoron.
Sekvas, de kie tiu valoro venas, kaj kiu skatolo rajtas ŝanĝi ĝin.
Rompitas la ŝarĝo, ne la tunelo
FTP metas la datuman finpunkton ene de la rega fluo. En aktiva reĝimo la kliento sendas PORT kun sia propra adreso kaj pordo, kaj la servilo revokas al tiu paro. En pasiva reĝimo la servilo respondas 227 kun paro, kaj la kliento anstataŭe vokas tiun.
Ambaŭ formoj portas la saman specon de aserto: konektiĝu al tiu adreso, sur tiu pordo. Aparato, kiu reskribas nur IP- kaj TCP-kapliniojn, lasas la aserton netuŝita, do unu flanko daŭre provas atingi adreson, kiu ekzistas nur sur la alia flanko de tunelo. La datuma konekto haltas post kiam la rega konekto jam estis deklarita sana.
Tri reĝimoj, tri ŝarĝoj
La suba tabelo montras, al kiu flanko oni diras voki, kaj kion NAT, kiu reskribas nur kapliniojn, povas fari pri tio.
Legu la lastan kolumnon kiel tion, kio unue fiaskas. En aktiva reĝimo la servilo estas tiu, kiu vokas privatan adreson; en pasiva reĝimo temas pri la kliento; ĉe FTPS la ŝarĝo estas ĉifrita teksto kaj la meza skatolo havas eĉ malpli kun kio labori.
| 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 |
Metu la helpeton tie, kie okazas la traduko
Sur Linux la reskribon de la ŝarĝo faras la helpeto nf_conntrack_ftp. Ĝi observas la regan konekton, lernas la intertraktitan pordon, kreas atendo por la datuma fluo kaj sur NAT-skatolo reskribas la adreson kaj pordon ene de la ŝarĝo. Ĝi helpas nur sur la aparato, kiu tradukas la adreson de la kliento. Ŝuti ĝin sur la klienton, aŭ sur enkursigilon, kiu nur plusendas la fluon, ŝanĝas nenion pri la sesio.
Ĉi tiuj tri ordonoj montras, ĉu la modulo ĉeestas, ĉu ĝi estas alligita, kaj ĉu atendo ekzistas dum sesio estas malfermita:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpŜuti la modulon ne samas kiel alligi ĝin. Kernoj ekde 4.7 venas kun net.netfilter.nf_conntrack_helper=0, do la helpeto atendas eksplicitan regulon, ekzemple iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Se la atenda listo restas malplena dum oni provas transdonon, la alligo estas tio, kion kontroli, ne la modulo.
Pasiva reĝimo: diru al la servilo, kion anonci
Pasivan reĝimon pli facile eblas igi determinisma, ĉar oni povas diri al la servilo, kion meti en la respondon 227. En vsftpd tio estas pasv_address, kune kun pasv_min_port kaj pasv_max_port; ProFTPD uzas MasqueradeAddress kaj PassivePorts. Agordu tiujn unue, ĉar ĝuste anoncita adreso forigas la bezonon reskribi ion ajn sur tiu flanko.
Poste lasu ĝuste tiun pordan intervalon tra la enirejo, ekzemple -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, por ke la regulo kongruu kun tio, kion la servilo anoncas.
La du agordoj devas kongrui. Servilo, al kiu oni diras anonci 30000-30100 dum la enirejo permesas 40000-40100, fiaskas la plej nehelpan manieron: la rega interparolo aspektas sana kaj ĉiu datuma konekto mortas. Komparu la nombrojn antaŭ ol senerarigi ion ajn alian.
Du fiaskaj signoj, kaj kion forigas FTPS
Halto ĉe LIST montras al la unua datuma konekto de la sesio, kie kaj la adresa reskribo kaj la atendo devas funkcii. Halto ĉe RETR post funkcianta LIST montras al la transdono mem, do al la pasiva intervalo aŭ al la MTU de la tunelo. Tiu dua signo ne estas ŝarĝa problemo, kaj agordoj de la helpeto ne riparos ĝin.
FTP super TLS forigas la ŝarĝon, kiun legas la helpeto. Meza skatolo ne povas reskribi valoron PORT aŭ PASV, kiun ĝi ne povas malĉifri, do restas prokuro, kiu finas TLS, servilo, kiu anoncas atingeblan adreson en limigita intervalo, aŭ alia transdona protokolo.
Mallonga ordo de kontroloj
Laboru de la simptomo eksteren. Konfirmu, ke LIST fiaskas dum PWD sukcesas, kaptu la adreson ene de la ŝarĝo PORT aŭ 227, kaj demandu, kiu aparato tradukas tiun adreson. Alligu la helpeton tie, observu la atendant liston dum unu transdono, poste ripari la pasivan reĝimon sur la servilo kaj spegulu la intervalon en la enireja regulo.
Tenu la fiaskon de la datuma vojo aparte de la fiasko de amasa transdono, ĉar ili sendas vin al malsamaj agordoj.