Miksi FTP-listaukset jämähtävät NAT:ia tekevän VPN-yhdyskäytävän taakse
Kirjautuminen ja PWD onnistuvat, kun taas LIST ja RETR pysähtyvät, kun NAT kirjoittaa uudelleen vain otsakkeet. Katso, mihin FTP-avustajan kuuluu sijoittua ja miten passiivinen tila korjataan.
Kirjautuminen toimii, PWD toimii, ja sitten LIST jämähtää, kunnes asiakas luovuttaa tai siirtyy toiseen datatilaan. Tämä jakautuminen on tunnusmerkki: ohjausyhteys porttiin 21 on terve, kun taas datayhteys rakennetaan osoitteesta tai portista, johon toinen pää ei pääse. Sellaisen VPN-yhdyskäytävän takana, joka tekee myös NAT:ia, tavallinen syyllinen on FTP-komento, jonka hyötykuorma nimeää tunneliosoitteen kuten 10.8.0.6. Otsakkeiden käännös ei koskaan kosketa tuota arvoa.
Seuraavaksi selviää, mistä tuo arvo tulee ja mikä laatikko saa muuttaa sitä.
Rikki menee hyötykuorma, ei tunneli
FTP sijoittaa datan päätepisteen ohjausvirran sisään. Aktiivisessa tilassa asiakas lähettää PORT-komennon omalla osoitteellaan ja portillaan, ja palvelin soittaa takaisin tuohon pariin. Passiivisessa tilassa palvelin vastaa 227:llä ja parilla, ja asiakas soittaa sen sijaan siihen.
Molemmat muodot kantavat samanlaista väitettä: yhdistä tähän osoitteeseen, tällä portilla. Laite, joka kirjoittaa uudelleen vain IP- ja TCP-otsakkeet, jättää väitteen rauhaan, joten toinen pää yrittää edelleen päästä osoitteeseen, joka on olemassa vain tunnelin toisella puolella. Datayhteys pysähtyy sen jälkeen, kun ohjausyhteys on jo julistettu terveeksi.
Kolme tilaa, kolme hyötykuormaa
Alla oleva taulukko näyttää, kummalle puolelle sanotaan, että sen pitää soittaa, ja mitä vain otsakkeet uudelleen kirjoittava NAT voi tehdä asialle.
Lue viimeinen sarake asiana, joka pettää ensimmäisenä. Aktiivisessa tilassa palvelin soittaa yksityiseen osoitteeseen; passiivisessa tilassa asiakas; FTPS:ssä hyötykuorma on salattua tekstiä ja välilaatikolla on vielä vähemmän, millä työskennellä.
| 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 |
Sijoita avustaja sinne, missä käännös tapahtuu
Linuxissa hyötykuorman uudelleenkirjoituksen tekee avustaja nf_conntrack_ftp. Se seuraa ohjausyhteyttä, oppii neuvotellun portin, luo odotuksen datavirralle ja kirjoittaa NAT-laatikossa uudelleen hyötykuorman sisällä olevan osoitteen ja portin. Se auttaa vain laitteessa, joka kääntää asiakkaan osoitteen. Sen lataaminen asiakkaalle tai reitittimelle, joka vain välittää virran eteenpäin, ei muuta istunnossa mitään.
Nämä kolme komentoa näyttävät, onko moduuli paikalla, onko se kiinnitetty ja onko odotus olemassa, kun istunto on auki:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpModuulin lataaminen ei ole sama kuin sen kiinnittäminen. Ytimet 4.7:stä alkaen tulevat mukana net.netfilter.nf_conntrack_helper=0, joten avustaja odottaa nimenomaista sääntöä, esimerkiksi iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Jos odotuslista pysyy tyhjänä siirtoa yritettäessä, tarkistettava asia on kiinnitys, ei moduuli.
Passiivinen tila: kerro palvelimelle, mitä sen pitää mainostaa
Passiivinen tila on helpompi tehdä deterministiseksi, koska palvelimelle voi kertoa, mitä se laittaa 227-vastaukseen. vsftpd:ssä se on pasv_address yhdessä pasv_min_port- ja pasv_max_port-asetusten kanssa; ProFTPD käyttää MasqueradeAddress- ja PassivePorts-asetuksia. Aseta ne ensin, sillä oikein mainostettu osoite poistaa tarpeen kirjoittaa mitään uudelleen sillä puolella.
Päästä sitten juuri tuo porttialue yhdyskäytävän läpi, esimerkiksi -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, jotta sääntö vastaa sitä, mitä palvelin mainostaa.
Kahden asetuksen on oltava yhtäpitäviä. Palvelin, jolle sanotaan, että sen pitää mainostaa 30000-30100, kun yhdyskäytävä sallii 40000-40100, epäonnistuu vähiten hyödyllisellä tavalla: ohjauskeskustelu näyttää terveeltä ja jokainen datayhteys kuolee. Vertaa lukuja ennen kuin alat selvittää mitään muuta.
Kaksi vikatunnusmerkkiä ja mitä FTPS poistaa
Jämähtäminen LIST-komennossa viittaa istunnon ensimmäiseen datayhteyteen, jossa sekä osoitteen uudelleenkirjoituksen että odotuksen on toimittava. Jämähtäminen RETR-komennossa toimivan LIST-komennon jälkeen viittaa itse siirtoon, eli passiiviseen alueeseen tai tunnelin MTU:hun. Tuo toinen tunnusmerkki ei ole hyötykuorman ongelma, eivätkä avustajan asetukset korjaa sitä.
FTP TLS:n päällä poistaa hyötykuorman, jota avustaja lukee. Välilaatikko ei voi kirjoittaa uudelleen PORT- tai PASV-arvoa, jota se ei pysty purkamaan, joten jäljelle jäävät vaihtoehdot ovat TLS:n päättävä välityspalvelin, palvelin joka mainostaa tavoitettavissa olevaa osoitetta rajatulla alueella, tai eri siirtoprotokolla.
Lyhyt tarkistusjärjestys
Työskentele oireesta ulospäin. Varmista, että LIST epäonnistuu PWD:n onnistuessa, sieppaa osoite PORT- tai 227-hyötykuorman sisältä ja kysy, mikä laite kääntää tuon osoitteen. Kiinnitä avustaja sinne, seuraa odotuslistaa yhden siirron ajan, korjaa sitten passiivinen tila palvelimella ja peilaa alue yhdyskäytävän sääntöön.
Pidä datapolun vika erillään massasiirron viasta, koska ne vievät sinut eri asetuksiin.