Hvorfor FTP-lister hænger bag en VPN-gateway, der laver NAT

Login virker, PWD virker, og så hænger LIST, indtil klienten giver op eller skifter til en anden datatilstand. Den opdeling er signaturen: kontrolforbindelsen til port 21 er sund, mens dataforbindelsen bygges fra en adresse eller port, som den anden side ikke kan nå. Bag en VPN-gateway, der også laver NAT, er den sædvanlige synder en FTP-kommando, hvis nyttelast nævner en tunneladresse som 10.8.0.6. Headeroversættelse rører aldrig den værdi.

Det følgende er, hvor den værdi kommer fra, og hvilken boks der må ændre den.

Det er nyttelasten, der knækker, ikke tunnelen

FTP lægger datapunktet inde i kontrolstrømmen. I aktiv tilstand sender klienten PORT med sin egen adresse og port, og serveren ringer tilbage til den tuple. I passiv tilstand svarer serveren 227 med en tuple, og klienten ringer i stedet til den.

Begge former bærer samme slags udsagn: forbind til denne adresse, på denne port. En enhed, der kun omskriver IP- og TCP-headere, lader udsagnet være, så den ene ende bliver ved med at forsøge at nå en adresse, der kun findes på den anden side af en tunnel. Dataforbindelsen går i stå, efter at kontrolforbindelsen allerede er erklæret sund.

Tre tilstande, tre nyttelaster

Tabellen nedenfor viser, hvilken side der får besked om at ringe, og hvad en NAT, der kun omskriver headere, kan gøre ved det.

Læs den sidste kolonne som det, der fejler først. I aktiv tilstand er det serveren, der ringer til en privat adresse; i passiv tilstand er det klienten; med FTPS er nyttelasten ciphertext, og mellemboksen har endnu mindre at arbejde med.

Sæt hjælperen der, hvor oversættelsen sker

På Linux udføres omskrivningen af nyttelasten af hjælperen nf_conntrack_ftp. Den overvåger kontrolforbindelsen, lærer den port, der blev forhandlet, opretter en forventning til dataflowet og omskriver på en NAT-boks adressen og porten inde i nyttelasten. Den hjælper kun på den enhed, der oversætter klientens adresse. At indlæse den på klienten eller på en router, der blot videresender flowet, ændrer intet ved sessionen.

Disse tre kommandoer viser, om modulet er til stede, om det er tilknyttet, og om der findes en forventning, mens en session er åben:

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

At indlæse modulet er ikke det samme som at tilknytte det. Kerner fra 4.7 og frem leveres med net.netfilter.nf_conntrack_helper=0, så hjælperen venter på en udtrykkelig regel, for eksempel iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Hvis forventningslisten forbliver tom, mens en overførsel forsøges, er det tilknytningen, der skal undersøges, ikke modulet.

Passiv tilstand: fortæl serveren, hvad den skal annoncere

Passiv tilstand er lettere at gøre deterministisk, fordi serveren kan få besked om, hvad den skal sætte i 227-svaret. I vsftpd er det pasv_address sammen med pasv_min_port og pasv_max_port; ProFTPD bruger MasqueradeAddress og PassivePorts. Sæt dem først, fordi en korrekt annonceret adresse fjerner behovet for at omskrive noget som helst på den side.

Slip derefter præcis det portinterval igennem gatewayen, for eksempel -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, så reglen matcher det, serveren annoncerer.

De to indstillinger skal stemme overens. En server, der får besked om at annoncere 30000-30100, mens gatewayen tillader 40000-40100, fejler på den mindst hjælpsomme måde: kontrolsamtalen ser sund ud, og hver dataforbindelse dør. Sammenlign tallene, før du fejlretter noget andet.

To fejlsignaturer, og hvad FTPS fjerner

Et hang på LIST peger på sessionens første dataforbindelse, hvor både adresseomskrivning og forventningen skal virke. Et hang på RETR efter et fungerende LIST peger på selve overførslen, altså det passive interval eller tunnelens MTU. Den anden signatur er ikke et nyttelastproblem, og hjælperindstillinger retter den ikke.

FTP over TLS fjerner den nyttelast, hjælperen læser. En mellemboks kan ikke omskrive en PORT- eller PASV-værdi, den ikke kan dekryptere, så de resterende valg er en proxy, der afslutter TLS, en server, der annoncerer en tilgængelig adresse inden for et afgrænset interval, eller en anden overførselsprotokol.

En kort rækkefølge af kontroller

Arbejd udad fra symptomet. Bekræft, at LIST fejler, mens PWD lykkes, fang adressen inde i PORT- eller 227-nyttelasten, og spørg, hvilken enhed der oversætter den adresse. Tilknyt hjælperen der, hold øje med forventningslisten under en overførsel, ret derefter passiv tilstand på serveren, og spejl intervallet i gateway-reglen.

Hold datavejsfejlen adskilt fra bulkoverførselsfejlen, fordi de sender dig til forskellige indstillinger.