Kodėl FTP sąrašai stringa už NAT atliekančio VPN šliuzo
Prisijungimas ir PWD pavyksta, o LIST bei RETR sustoja, kai NAT perrašo tik antraštes. Sužinokite, kur turi būti FTP pagalbininkas ir kaip sutvarkyti pasyvųjį režimą.
Prisijungimas veikia, PWD veikia, o tada LIST stringa, kol klientas pasiduoda arba pereina į kitą duomenų režimą. Šis atskyrimas ir yra požymis: valdymo ryšys į 21 prievadą sveikas, o duomenų ryšys statomas iš adreso ar prievado, kurio kita pusė negali pasiekti. Už VPN šliuzo, kuris taip pat atlieka NAT, įprastas kaltininkas yra FTP komanda, kurios naudingoji apkrova įvardija tunelio adresą, pavyzdžiui, 10.8.0.6. Antraščių vertimas niekada neliečia šios reikšmės.
Toliau – iš kur ta reikšmė atsiranda ir kuri dėžė turi teisę ją keisti.
Lūžta naudingoji apkrova, o ne tunelis
FTP įdeda duomenų galinį tašką į valdymo srautą. Aktyviuoju režimu klientas siunčia PORT su savo adresu ir prievadu, o serveris perskambina į tą porą. Pasyviuoju režimu serveris atsako 227 su pora, o klientas vietoj to skambina į ją.
Abi formos neša to paties tipo teiginį: prisijunk prie šio adreso, šiuo prievadu. Įrenginys, kuris perrašo tik IP ir TCP antraštes, palieka teiginį nepakeistą, todėl viena pusė toliau bando pasiekti adresą, kuris egzistuoja tik kitoje tunelio pusėje. Duomenų ryšys sustoja po to, kai valdymo ryšys jau paskelbtas sveiku.
Trys režimai, trys naudingosios apkrovos
Lentelė žemiau rodo, kuriai pusei liepiama skambinti, ir ką iš tikrųjų gali padaryti NAT, perrašantis tik antraštes.
Paskutinį stulpelį skaitykite kaip tai, kas sugenda pirmiausia. Aktyviuoju režimu skambina serveris į privatų adresą, pasyviuoju – klientas, o su FTPS naudingoji apkrova yra šifruotas tekstas, tad tarpinei dėžei lieka dar mažiau darbo.
| 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 |
Padėkite pagalbininką ten, kur vyksta vertimas
Linux sistemoje naudingąją apkrovą perrašo pagalbininkas nf_conntrack_ftp. Jis stebi valdymo ryšį, išmoksta suderėtą prievadą, sukuria lūkestį duomenų srautui ir NAT dėžėje perrašo adresą bei prievadą naudingosios apkrovos viduje. Jis padeda tik tame įrenginyje, kuris verčia kliento adresą. Įkėlus jį kliente arba maršrutizatoriuje, kuris tik perduoda srautą, sesijoje niekas nesikeičia.
Šios trys komandos parodo, ar modulis yra, ar jis prikabintas ir ar yra lūkestis, kol sesija atidaryta:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpĮkelti modulį nėra tas pats, kas jį prikabinti. Branduoliai nuo 4.7 ateina su net.netfilter.nf_conntrack_helper=0, todėl pagalbininkas laukia aiškios taisyklės, pavyzdžiui, iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Jei lūkesčių sąrašas lieka tuščias bandant perkelti, tikrinti reikia prikabinimą, o ne modulį.
Pasyvusis režimas: pasakykite serveriui, ką skelbti
Pasyvųjį režimą lengviau padaryti deterministinį, nes serveriui galima pasakyti, ką dėti į 227 atsakymą. vsftpd atveju tai pasv_address kartu su pasv_min_port ir pasv_max_port; ProFTPD naudoja MasqueradeAddress ir PassivePorts. Nustatykite tai pirmiausia, nes teisingai paskelbtas adresas panaikina poreikį toje pusėje ką nors perrašinėti.
Tada praleiskite būtent tą prievadų intervalą pro šliuzą, pavyzdžiui, -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, kad taisyklė atitiktų tai, ką serveris skelbia.
Abu nustatymai turi sutapti. Serveris, kuriam liepta skelbti 30000-30100, o šliuzas leidžia 40000-40100, sugenda mažiausiai naudingu būdu: valdymo pokalbis atrodo sveikas, o kiekvienas duomenų ryšys miršta. Palyginkite skaičius prieš taisydami ką nors kita.
Du gedimo požymiai ir ką pašalina FTPS
Stringimas ties LIST rodo į pirmąjį sesijos duomenų ryšį, kur turi veikti ir adreso perrašymas, ir lūkestis. Stringimas ties RETR po veikiančio LIST rodo į patį perkėlimą, tai yra pasyvųjį intervalą arba tunelio MTU. Šis antrasis požymis nėra naudingosios apkrovos problema, ir pagalbininko nustatymai jo nepataisys.
FTP per TLS pašalina naudingąją apkrovą, kurią skaito pagalbininkas. Tarpinė dėžė negali perrašyti PORT ar PASV reikšmės, kurios negali iššifruoti, todėl lieka TLS užbaigiantis tarpinis serveris, serveris, skelbiantis pasiekiamą adresą ribotame intervale, arba kitas perkėlimo protokolas.
Trumpa patikrų seka
Dirbkite nuo požymio į išorę. Patvirtinkite, kad LIST nepavyksta, o PWD pavyksta, užfiksuokite adresą PORT ar 227 naudingojoje apkrovoje ir paklauskite, kuris įrenginys verčia tą adresą. Prikabinkite ten pagalbininką, stebėkite lūkesčių sąrašą vieno perkėlimo metu, tada sutvarkykite pasyvųjį režimą serveryje ir atspindėkite intervalą šliuzo taisyklėje.
Laikykite duomenų kelio gedimą atskirai nuo masinio perkėlimo gedimo, nes jie veda prie skirtingų nustatymų.