Kvifor FTP-lister heng bak ein VPN-gateway som gjer NAT
Innlogging og PWD lukkast, medan LIST og RETR stoppar når NAT berre skriv om hovuda. Sjå kvar FTP-hjelparen må sitje, og korleis du rettar passiv modus.
Innlogginga verkar, PWD verkar, og då heng LIST til klienten gjev opp eller byter til ein annan datamodus. Denne delinga er signaturen: kontrollsambandet til port 21 er sunt, medan datasambandet vert bygd frå ei adresse eller ein port som den andre sida ikkje kan nå. Bak ein VPN-gateway som òg gjer NAT, er den vanlege syndaren ein FTP-kommando der nyttelasta nemner ei tunneladresse som 10.8.0.6. Omsetjinga av hovud tek aldri på den verdien.
Det som følgjer, er kvar den verdien kjem frå, og kva boks som har lov til å endre han.
Det som ryker er nyttelasta, ikkje tunnelen
FTP legg dataendepunktet inne i kontrollstraumen. I aktiv modus sender klienten PORT med si eiga adresse og port, og tenaren ringjer tilbake til den tuppelen. I passiv modus svarer tenaren 227 med ein tuppel, og klienten ringjer til den i staden.
Båe formene ber same slags utsegn: kople til denne adressa, på denne porten. Eininga som berre skriv om IP- og TCP-hovud let utsegna vere, så den eine enden held fram med å prøve å nå ei adresse som berre finst på den andre sida av ein tunnel. Datasambandet stoppar etter at kontrollsambandet alt er erklært sunt.
Tre modusar, tre nyttelaster
Tabellen nedanfor viser kva side som vert beden om å ringje, og kva ein NAT som berre skriv om hovud kan gjere med det.
Les den siste kolonnen som det som sviktar først. I aktiv modus er det tenaren som ringjer ei privat adresse; i passiv modus er det klienten; med FTPS er nyttelasta chiffertekst og mellomkassa har endå mindre å arbeide med.
| 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 |
Set hjelparen der omsetjinga skjer
På Linux gjer hjelparen nf_conntrack_ftp omskrivinga av nyttelasta. Han overvakar kontrollsambandet, lærer porten som vart forhandla, lagar ei forventning for dataflyten og skriv på ein NAT-boks om adressa og porten inne i nyttelasta. Han hjelper berre på eininga som omset klientadressa. Å laste han på klienten, eller på ein ruter som berre sender flyten vidare, endrar ingenting ved økta.
Desse tre kommandoane viser om modulen er til stades, om han er tilkopla, og om det finst ei forventning medan ei økt er open:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpÅ laste modulen er ikkje det same som å kople han til. Kjernar frå 4.7 og oppover kjem med net.netfilter.nf_conntrack_helper=0, så hjelparen ventar på ein uttrykkeleg regel, til dømes iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Om forventningslista blir ståande tom medan ei overføring vert prøvd, er det tilkoplinga som må sjekkast, ikkje modulen.
Passiv modus: fortel tenaren kva han skal annonsere
Passiv modus er lettare å gjere deterministisk fordi tenaren kan få beskjed om kva han skal setje i 227-svaret. I vsftpd er det pasv_address, saman med pasv_min_port og pasv_max_port; ProFTPD brukar MasqueradeAddress og PassivePorts. Set desse først, fordi ei rett annonsert adresse fjernar behovet for å skrive om noko som helst på den sida.
Slepp deretter nøyaktig det portområdet gjennom gatewayen, til dømes -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, slik at regelen stemmer med det tenaren annonserer.
Dei to innstillingane må stemme overeins. Ein tenar som får beskjed om å annonsere 30000-30100 medan gatewayen tillèt 40000-40100, sviktar på den minst hjelpsame måten: kontrollsamtalen ser sunn ut, og kvart datasamband døyr. Samanlikn tala før du feilsøkjer noko anna.
To feilsignaturar, og kva FTPS fjernar
Ein hang på LIST peikar på det første datasambandet i økta, der både adresseomskrivinga og forventninga må verke. Ein hang på RETR etter ein fungerande LIST peikar på sjølve overføringa, altså det passive området eller MTU-en til tunnelen. Den andre signaturen er ikkje eit nyttelastproblem, og hjelparinnstillingar rettar han ikkje.
FTP over TLS fjernar nyttelasta som hjelparen les. Ei mellomkasse kan ikkje skrive om ein PORT- eller PASV-verdi ho ikkje kan dekryptere, så dei attverande vala er ein proxy som avsluttar TLS, ein tenar som annonserer ei tilgjengeleg adresse innanfor eit avgrensa område, eller ein annan overføringsprotokoll.
Ein kort rekkjefølgje av kontrollar
Arbeid deg utover frå symptomet. Stadfest at LIST sviktar medan PWD lukkast, fang adressa inne i PORT- eller 227-nyttelasta, og spør kva eining som omset den adressa. Kople hjelparen der, følg med på forventningslista under éi overføring, rett deretter passiv modus på tenaren og spegle området i gateway-regelen.
Hald feilen i datapath skild frå feilen ved masseoverføring, fordi dei sender deg til ulike innstillingar.