Hvorfor FTP-lister henger bak en VPN-gateway som gjør NAT
Innlogging og PWD lykkes, mens LIST og RETR stopper når NAT bare skriver om overskriftene. Se hvor FTP-hjelperen må sitte, og hvordan du fikser passiv modus.
Innloggingen virker, PWD virker, og så henger LIST til klienten gir opp eller bytter til en annen datamodus. Denne delingen er signaturen: kontrollforbindelsen til port 21 er sunn, mens dataforbindelsen bygges fra en adresse eller port som den andre siden ikke kan nå. Bak en VPN-gateway som også gjør NAT, er den vanlige synderen en FTP-kommando der nyttelasten nevner en tunneladresse som 10.8.0.6. Oversettelsen av headere rører aldri den verdien.
Det som følger, er hvor den verdien kommer fra, og hvilken boks som har lov til å endre den.
Det som ryker er nyttelasten, ikke tunnelen
FTP legger dataendepunktet inne i kontrollstrømmen. I aktiv modus sender klienten PORT med sin egen adresse og port, og serveren ringer tilbake til den tuppelen. I passiv modus svarer serveren 227 med en tuppel, og klienten ringer til den i stedet.
Begge formene bærer samme type utsagn: koble til denne adressen, på denne porten. En enhet som bare skriver om IP- og TCP-headere lar utsagnet være, så den ene enden fortsetter å prøve å nå en adresse som bare finnes på den andre siden av en tunnel. Dataforbindelsen stopper etter at kontrollforbindelsen allerede er erklært sunn.
Tre moduser, tre nyttelaster
Tabellen nedenfor viser hvilken side som blir bedt om å ringe, og hva en NAT som bare skriver om headere kan gjøre med det.
Les den siste kolonnen som det som svikter først. I aktiv modus er det serveren som ringer en privat adresse; i passiv modus er det klienten; med FTPS er nyttelasten chiffertekst og mellomkassen har enda 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 |
Sett hjelperen der oversettelsen skjer
På Linux gjøres omskrivingen av nyttelasten av hjelperen nf_conntrack_ftp. Den overvåker kontrollforbindelsen, lærer porten som ble forhandlet, lager en forventning for dataflyten og skriver på en NAT-boks om adressen og porten inne i nyttelasten. Den hjelper bare på enheten som oversetter klientens adresse. Å laste den på klienten, eller på en ruter som bare videresender flyten, endrer ingenting ved økten.
Disse tre kommandoene viser om modulen er til stede, om den er tilkoblet, og om det finnes en forventning mens en økt er åpen:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpÅ laste modulen er ikke det samme som å koble den til. Kjerner fra 4.7 og utover leveres med net.netfilter.nf_conntrack_helper=0, så hjelperen venter på en uttrykkelig regel, for eksempel iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Hvis forventningslisten blir stående tom mens en overføring forsøkes, er det tilkoblingen som må sjekkes, ikke modulen.
Passiv modus: fortell serveren hva den skal annonsere
Passiv modus er lettere å gjøre deterministisk fordi serveren kan få beskjed om hva den skal sette i 227-svaret. I vsftpd er det pasv_address, sammen med pasv_min_port og pasv_max_port; ProFTPD bruker MasqueradeAddress og PassivePorts. Sett disse først, fordi en riktig annonsert adresse fjerner behovet for å skrive om noe som helst på den siden.
Slipp deretter nøyaktig det portområdet gjennom gatewayen, for eksempel -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, slik at regelen stemmer med det serveren annonserer.
De to innstillingene må stemme overens. En server som får beskjed om å annonsere 30000-30100 mens gatewayen tillater 40000-40100, svikter på den minst hjelpsomme måten: kontrollsamtalen ser sunn ut, og hver dataforbindelse dør. Sammenlign tallene før du feilsøker noe annet.
To feilsignaturer, og hva FTPS fjerner
En henging på LIST peker på øktens første dataforbindelse, der både adresseomskrivingen og forventningen må virke. En henging på RETR etter en fungerende LIST peker på selve overføringen, altså det passive området eller tunnels MTU. Den andre signaturen er ikke et nyttelastproblem, og hjelperinnstillinger retter den ikke.
FTP over TLS fjerner nyttelasten som hjelperen leser. En mellomkasse kan ikke skrive om en PORT- eller PASV-verdi den ikke kan dekryptere, så de gjenværende valgene er en proxy som avslutter TLS, en server som annonserer en tilgjengelig adresse innenfor et avgrenset område, eller en annen overføringsprotokoll.
En kort rekkefølge av kontroller
Arbeid deg utover fra symptomet. Bekreft at LIST svikter mens PWD lykkes, fang adressen inne i PORT- eller 227-nyttelasten, og spør hvilken enhet som oversetter den adressen. Koble hjelperen der, følg med på forventningslisten under én overføring, fiks deretter passiv modus på serveren og speil området i gateway-regelen.
Hold feilen i datapath adskilt fra feilen ved masseoverføring, fordi de sender deg til forskjellige innstillinger.