Per què les llistes FTP es pengen darrere una passarel·la VPN que fa NAT

L’inici de sessió funciona, PWD funciona, i llavors LIST es penja fins que el client es rendeix o passa a un altre mode de dades. Aquesta divisió és la signatura: la connexió de control al port 21 és sana, mentre que la connexió de dades es construeix des d’una adreça o un port que l’altre extrem no pot assolir. Darrere una passarel·la VPN que també fa NAT, el culpable habitual és una ordre FTP la càrrega de la qual anomena una adreça de túnel com 10.8.0.6. La traducció de capçaleres no toca mai aquest valor.

A continuació ve d’on surt aquest valor i quina caixa té permís per canviar-lo.

El que es trenca és la càrrega, no el túnel

L’FTP posa el punt final de dades dins del flux de control. En mode actiu el client envia PORT amb la seva pròpia adreça i port, i el servidor torna la trucada a aquesta tupla. En mode passiu el servidor respon 227 amb una tupla, i el client truca aquesta en lloc seu.

Totes dues formes porten la mateixa mena d’afirmació: connecta’t a aquesta adreça, en aquest port. Un dispositiu que només reescriu capçaleres IP i TCP deixa l’afirmació intacta, així que un extrem continua intentant assolir una adreça que només existeix a l’altre costat d’un túnel. La connexió de dades s’atura després que la connexió de control ja s’hagi declarat bona.

Tres modes, tres càrregues

La taula següent mostra a quin costat se li diu que truqui, i què pot fer-hi un NAT que només reescriu capçaleres.

Llegiu l’última columna com la cosa que falla primer. En mode actiu és el servidor qui truca a una adreça privada; en mode passiu és el client; amb FTPS la càrrega és text xifrat i la caixa intermèdia té encara menys amb què treballar.

Poseu l’auxiliar on passa la traducció

A Linux la reescriptura de la càrrega la fa l’auxiliar nf_conntrack_ftp. Vigila la connexió de control, aprèn el port que s’ha negociat, crea una expectativa per al flux de dades i, en una caixa NAT, reescriu l’adreça i el port dins de la càrrega. Només ajuda al dispositiu que tradueix l’adreça del client. Carregar-lo al client, o en un encaminador que només reenvia el flux, no canvia res de la sessió.

Aquestes tres ordres mostren si el mòdul hi és, si està enganxat i si hi ha una expectativa mentre una sessió és oberta:

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

Carregar el mòdul no és el mateix que enganxar-lo. Els nuclis des del 4.7 ençà venen amb net.netfilter.nf_conntrack_helper=0, així que l’auxiliar espera una regla explícita, per exemple iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Si la llista d’expectatives queda buida mentre s’intenta una transferència, el que cal comprovar és l’enganxament, no el mòdul.

Mode passiu: digueu al servidor què ha d’anunciar

El mode passiu és més fàcil de fer determinista perquè es pot dir al servidor què ha de posar a la resposta 227. A vsftpd això és pasv_address, juntament amb pasv_min_port i pasv_max_port; ProFTPD fa servir MasqueradeAddress i PassivePorts. Definiu-ho primer, ja que una adreça anunciada correcta elimina la necessitat de reescriure res en aquell costat.

Després deixeu passar exactament aquest rang de ports per la passarel·la, per exemple -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, perquè la regla coincideixi amb el que anuncia el servidor.

Els dos ajustos s’han de correspondre. Un servidor al qual es diu que anunciï 30000-30100 mentre la passarel·la permet 40000-40100 falla de la manera menys útil: la conversa de control sembla sana i tota connexió de dades mor. Compareu els números abans de depurar res més.

Dues signatures de fallada, i què elimina FTPS

Una penjada a LIST apunta a la primera connexió de dades de la sessió, on tant la reescriptura d’adreça com l’expectativa han de funcionar. Una penjada a RETR després d’un LIST que funciona apunta a la transferència mateixa, és a dir al rang passiu o a l’MTU del túnel. Aquesta segona signatura no és un problema de càrrega, i els ajustos de l’auxiliar no la arreglaran.

L’FTP sobre TLS elimina la càrrega que llegeix l’auxiliar. Una caixa intermèdia no pot reescriure un valor PORT o PASV que no pot desxifrar, així que queden un proxy que acaba el TLS, un servidor que anuncia una adreça abastable dins d’un rang limitat, o un protocol de transferència diferent.

Un ordre breu de comprovacions

Treballeu del símptoma cap enfora. Confirmeu que LIST falla mentre PWD té èxit, captureu l’adreça dins de la càrrega PORT o 227, i pregunteu quin dispositiu tradueix aquesta adreça. Enganxeu-hi l’auxiliar, observeu la llista d’expectatives durant una transferència, i després arregleu el mode passiu al servidor i reflectiu el rang a la regla de la passarel·la.

Manteniu la fallada del camí de dades separada de la fallada de transferència massiva, perquè us porten a ajustos diferents.