Varför FTP-listningar hänger bakom en VPN-gateway som gör NAT

Inloggningen fungerar, PWD fungerar, och sedan hänger LIST tills klienten ger upp eller byter till ett annat dataläge. Den uppdelningen är signaturen: kontrollanslutningen till port 21 är frisk, medan dataanslutningen byggs från en adress eller port som andra sidan inte kan nå. Bakom en VPN-gateway som också gör NAT är den vanliga boven ett FTP-kommando vars nyttolast anger en tunneladress som 10.8.0.6. Översättningen av rubriker rör aldrig det värdet.

Det som följer är var värdet kommer ifrån, och vilken burk som får ändra det.

Det som går sönder är nyttolasten, inte tunneln

FTP lägger dataändpunkten inne i kontrollströmmen. I aktivt läge skickar klienten PORT med sin egen adress och port, och servern ringer tillbaka till den tupeln. I passivt läge svarar servern 227 med en tupel, och klienten ringer den i stället.

Båda formerna bär samma sorts påstående: anslut till den här adressen, på den här porten. En enhet som bara skriver om IP- och TCP-rubriker lämnar påståendet i fred, så ena sidan fortsätter att försöka nå en adress som bara finns på andra sidan av en tunnel. Dataanslutningen stannar efter att kontrollanslutningen redan har förklarats frisk.

Tre lägen, tre nyttolaster

Tabellen nedan visar vilken sida som ombeds ringa, och vad en NAT som bara skriver om rubriker kan göra åt saken.

Läs den sista kolumnen som det som fallerar först. I aktivt läge är det servern som ringer en privat adress; i passivt läge är det klienten; med FTPS är nyttolasten chiffertext och mellanburken har ännu mindre att arbeta med.

Sätt hjälparen där översättningen sker

På Linux gör hjälparen nf_conntrack_ftp omskrivningen av nyttolasten. Den övervakar kontrollanslutningen, lär sig porten som förhandlades, skapar en förväntan för dataflödet och skriver på en NAT-burk om adressen och porten inne i nyttolasten. Den hjälper bara på enheten som översätter klientens adress. Att ladda den på klienten, eller på en router som bara vidarebefordrar flödet, ändrar ingenting i sessionen.

De här tre kommandona visar om modulen finns, om den är ansluten och om en förväntan finns medan en session är öppen:

modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftp

Att ladda modulen är inte samma sak som att ansluta den. Kärnor från 4.7 och framåt levereras med net.netfilter.nf_conntrack_helper=0, så hjälparen väntar på en uttrycklig regel, till exempel iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Om förväntelistan förblir tom medan en överföring försöks, är det anslutningen som ska kontrolleras, inte modulen.

Passivt läge: tala om för servern vad den ska annonsera

Passivt läge är lättare att göra deterministiskt eftersom servern kan få veta vad den ska sätta i 227-svaret. I vsftpd är det pasv_address, tillsammans med pasv_min_port och pasv_max_port; ProFTPD använder MasqueradeAddress och PassivePorts. Ange dem först, eftersom en korrekt annonserad adress tar bort behovet av att skriva om något på den sidan.

Släpp sedan igenom exakt det portintervallet genom gatewayen, till exempel -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, så att regeln stämmer med det servern annonserar.

De två inställningarna måste stämma överens. En server som får veta att den ska annonsera 30000-30100 medan gatewayen tillåter 40000-40100 misslyckas på det minst hjälpsamma sättet: kontrollsamtalet ser friskt ut och varje dataanslutning dör. Jämför siffrorna innan du felsöker något annat.

Två felsignaturer, och vad FTPS tar bort

En hängning på LIST pekar på sessionens första dataanslutning, där både adressomskrivningen och förväntan måste fungera. En hängning på RETR efter en fungerande LIST pekar på själva överföringen, det vill säga det passiva intervallet eller tunnelns MTU. Den andra signaturen är inte ett nyttolastproblem, och hjälparinställningar åtgärdar den inte.

FTP över TLS tar bort nyttolasten som hjälparen läser. En mellanburk kan inte skriva om ett PORT- eller PASV-värde som den inte kan dekryptera, så kvar står en proxy som avslutar TLS, en server som annonserar en nåbar adress inom ett begränsat intervall, eller ett annat överföringsprotokoll.

En kort ordning av kontroller

Arbeta utåt från symptomet. Bekräfta att LIST misslyckas medan PWD lyckas, fånga adressen inne i PORT- eller 227-nyttolasten, och fråga vilken enhet som översätter den adressen. Anslut hjälparen där, följ förväntelistan under en överföring, åtgärda sedan passivt läge på servern och spegla intervallet i gatewayregeln.

Håll felet i datavägen åtskilt från felet vid massöverföring, eftersom de leder till olika inställningar.