Zakaj se seznami FTP zataknejo za prehodom VPN, ki izvaja NAT
Prijava in PWD uspeta, medtem ko se LIST in RETR ustavita, ko NAT prepisuje samo glave. Poglejte, kje mora sedeti pomočnik FTP in kako popraviti pasivni način.
Prijava deluje, PWD deluje, nato pa LIST visi, dokler odjemalec ne obupa ali ne preide v drug način podatkov. Ta razcep je podpis: krmilna povezava do vrat 21 je zdrava, medtem ko se podatkovna povezava gradi z naslova ali vrat, ki jih druga stran ne more doseči. Za prehodom VPN, ki izvaja tudi NAT, je običajni krivec ukaz FTP, katerega koristna obremenitev navaja naslov tunela, kot je 10.8.0.6. Prevajanje glav se te vrednosti nikoli ne dotakne.
Sledi, od kod ta vrednost prihaja in katera škatla jo sme spremeniti.
Zlomi se koristna obremenitev, ne tunel
FTP postavi končno točko podatkov znotraj krmilnega toka. V aktivnem načinu odjemalec pošlje PORT z lastnim naslovom in vrati, strežnik pa pokliče nazaj na ta par. V pasivnem načinu strežnik odgovori 227 s parom, odjemalec pa pokliče tega namesto tega.
Obe obliki nosita enako vrsto izjave: poveži se s tem naslovom, na teh vratih. Naprava, ki prepisuje samo glave IP in TCP, izjavo pusti pri miru, zato se ena stran še naprej trudi doseči naslov, ki obstaja samo na drugi strani tunela. Podatkovna povezava se ustavi potem, ko je bila krmilna povezava že razglašena za zdravo.
Trije načini, tri koristne obremenitve
Spodnja tabela prikazuje, kateri strani je ukazano klicati, in kaj lahko glede tega stori NAT, ki prepisuje samo glave.
Zadnji stolpec berite kot tisto, kar odpove prvo. V aktivnem načinu na zasebni naslov kliče strežnik, v pasivnem odjemalec, pri FTPS pa je koristna obremenitev šifrirano besedilo in vmesna škatla ima še manj, s čimer lahko dela.
| 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 |
Pomočnika postavite tja, kjer se prevajanje dogaja
V Linuxu prepisovanje koristne obremenitve izvaja pomočnik nf_conntrack_ftp. Opazuje krmilno povezavo, nauči se izpogajana vrata, ustvari pričakovanje za podatkovni tok in na škatli NAT prepiše naslov in vrata znotraj koristne obremenitve. Pomaga samo na napravi, ki prevaja naslov odjemalca. Nalaganje na odjemalcu ali na usmerjevalniku, ki tok samo posreduje, v seji ne spremeni ničesar.
Ti trije ukazi pokažejo, ali je modul prisoten, ali je pripet in ali med odprto sejo obstaja pričakovanje:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpNaložiti modul ni isto kot ga pripeti. Jedra od 4.7 naprej prihajajo z net.netfilter.nf_conntrack_helper=0, zato pomočnik čaka na izrecno pravilo, na primer iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Če seznam pričakovanj ostane prazen med poskusom prenosa, je treba preveriti pripetje, ne modula.
Pasivni način: povejte strežniku, kaj naj oglašuje
Pasivni način je lažje narediti determinističen, ker lahko strežniku poveste, kaj naj vstavi v odgovor 227. V vsftpd je to pasv_address skupaj s pasv_min_port in pasv_max_port; ProFTPD uporablja MasqueradeAddress in PassivePorts. Nastavite to najprej, ker pravilno oglaševan naslov odpravi potrebo po prepisovanju česarkoli na tisti strani.
Nato spustite skozi prehod točno to območje vrat, na primer -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, da se pravilo ujema s tem, kar strežnik oglašuje.
Nastavitvi se morata ujemati. Strežnik, ki mu je rečeno, naj oglašuje 30000-30100, medtem ko prehod dovoljuje 40000-40100, odpove na najmanj koristen način: krmilni pogovor je videti zdrav in vsaka podatkovna povezava umre. Primerjajte številke, preden kar koli drugega razhroščujete.
Dva podpisa okvare in kaj FTPS odstrani
Visenje na LIST kaže na prvo podatkovno povezavo seje, kjer morata delovati tako prepis naslova kot pričakovanje. Visenje na RETR po delujočem LIST kaže na sam prenos, torej na pasivno območje ali MTU tunela. Ta drugi podpis ni težava koristne obremenitve in nastavitve pomočnika ga ne bodo popravile.
FTP prek TLS odstrani koristno obremenitev, ki jo bere pomočnik. Vmesna škatla ne more prepisati vrednosti PORT ali PASV, ki je ne zna dešifrirati, zato ostanejo proxy, ki zaključi TLS, strežnik, ki oglašuje dosegljiv naslov v omejenem območju, ali drug prenosni protokol.
Kratek vrstni red preverjanj
Delajte od simptoma navzven. Potrdite, da LIST odpove, medtem ko PWD uspe, ujemite naslov znotraj obremenitve PORT ali 227 in vprašajte, katera naprava prevaja ta naslov. Pripnite pomočnika tja, opazujte seznam pričakovanj med enim prenosom, nato popravite pasivni način na strežniku in zrcalite območje v pravilu prehoda.
Okvaro na podatkovni poti imejte ločeno od okvare pri množičnem prenosu, ker vodita do različnih nastavitev.