Miks FTP-loendid jäävad VPN-lüüsi taha rippuma, kui see teeb NAT-i
Sisselogimine ja PWD õnnestuvad, samas kui LIST ja RETR takerduvad, kui NAT kirjutab ümber ainult päiseid. Vaadake, kuhu peab FTP-abiline paigutama, ja kuidas passiivset režiimi parandada.
Sisselogimine töötab, PWD töötab, ja siis LIST ripub, kuni klient annab alla või läheb üle teisele andmerežiimile. See lõhenemine ongi tunnus: juhtühendus pordile 21 on terve, samal ajal kui andmeühendus ehitatakse aadressilt või pordilt, milleni teine pool ei ulatu. VPN-lüüsi taga, mis teeb ka NAT-i, on tavaline süüdlane FTP-käsk, mille kandev osa nimetab tunneliaadressi nagu 10.8.0.6. Päiste tõlkimine ei puuduta seda väärtust kunagi.
Järgnev räägib, kust see väärtus tuleb ja milline kast tohib seda muuta.
Katki läheb kandev osa, mitte tunnel
FTP paneb andmete lõpp-punkti juhtvoo sisse. Aktiivses režiimis saadab klient PORT-i oma aadressi ja pordiga ning server helistab sellele paarile tagasi. Passiivses režiimis vastab server 227-ga koos paari andmetega ning klient helistab hoopis sellele.
Mõlemad vormid kannavad sama tüüpi väidet: ühendu selle aadressiga, sellel pordil. Seade, mis kirjutab ümber ainult IP- ja TCP-päiseid, jätab väite puutumata, nii et üks ots proovib edasi jõuda aadressini, mis eksisteerib ainult tunneli teisel poolel. Andmeühendus takerdub pärast seda, kui juhtühendus on juba terveks kuulutatud.
Kolm režiimi, kolm kandvat osa
Allolev tabel näitab, kummal poolel kästakse helistada, ja mida saab ainult päiseid ümber kirjutav NAT sellega teha.
Lugege viimast veergu kui asja, mis esimesena läbi kukub. Aktiivses režiimis on server see, kes helistab privaatsele aadressile; passiivses režiimis on selleks klient; FTPS-i puhul on kandev osa šifreeritud tekst ja vaheline kast peab veel vähemaga hakkama saama.
| 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 |
Pange abiline sinna, kus tõlkimine toimub
Linuxis teeb kandva osa ümberkirjutamist abiline nf_conntrack_ftp. See jälgib juhtühendust, õpib ära kokku lepitud pordi, loob andmevoo jaoks ootuse ja kirjutab NAT-kastis ümber kandva osa sees oleva aadressi ja pordi. See aitab ainult seadmel, mis tõlgib kliendi aadressi. Selle laadimine kliendile või ruuterile, mis voogu ainult edasi suunab, ei muuda sessiooni juures midagi.
Need kolm käsku näitavad, kas moodul on olemas, kas see on külge pandud ja kas avatud sessiooni ajal on ootus olemas:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpMooduli laadimine ei ole sama, mis selle külge panemine. Alates 4.7-st tulevad tuumad kaasa net.netfilter.nf_conntrack_helper=0, seega abiline ootab selgesõnalist reeglit, näiteks iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Kui ootuste loend jääb tühjaks, kui ülekannet proovitakse, siis tuleb kontrollida külgepanekut, mitte moodulit.
Passiivne režiim: öelge serverile, mida reklaamida
Passiivset režiimi on lihtsam deterministlikuks teha, sest serverile saab öelda, mida 227 vastusesse panna. Vsftpd-s on selleks pasv_address koos pasv_min_port ja pasv_max_port; ProFTPD kasutab MasqueradeAddress ja PassivePorts. Seadke need esimesena, sest õigesti reklaamitud aadress võtab ära vajaduse sellel poolel midagi ümber kirjutada.
Seejärel laske täpselt see pordivahemik lüüsist läbi, näiteks -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, et reegel klapiks sellega, mida server reklaamib.
Kaks seadet peavad omavahel kokku minema. Server, kellele öeldakse reklaamida 30000-30100, samal ajal kui lüüs lubab 40000-40100, kukub läbi kõige vähem abistaval moel: juhtvestlus näeb terve välja ja iga andmeühendus sureb. Võrrelge numbreid enne, kui hakkate midagi muud siluma.
Kaks rikke tunnust ja mida FTPS ära võtab
LIST-i juures takerdumine osutab sessiooni esimesele andmeühendusele, kus peavad töötama nii aadressi ümberkirjutamine kui ka ootus. RETR-i juures takerdumine pärast töötavat LIST-i osutab ülekandele endale, see tähendab passiivsele vahemikule või tunneli MTU-le. See teine tunnus ei ole kandva osa probleem ja abilise seaded ei paranda seda.
FTP üle TLS-i võtab ära kandva osa, mida abiline loeb. Vaheline kast ei saa ümber kirjutada PORT- ega PASV-väärtust, mida ta ei suuda dekrüpteerida, nii et alles jäävad TLS-i lõpetav puhverserver, server, mis reklaamib kättesaadavat aadressi piiratud vahemikus, või teine ülekandeprotokoll.
Lühike kontrollide järjekord
Töötage sümptomist väljapoole. Kinnitage, et LIST kukub läbi, samal ajal kui PWD õnnestub, püüdke kinni aadress PORT-i või 227 kandva osa sees ja küsige, milline seade seda aadressi tõlgib. Pange abiline sinna külge, jälgige ühe ülekande ajal ootuste loendit, seejärel parandage serveris passiivne režiim ja peegeldage vahemik lüüsi reeglisse.
Hoidke andmetee riket lahus hulgiülekande rikkest, sest need saadavad teid erinevate seadeteni.