Por que os listados FTP se colgan detrás dunha pasarela VPN que fai NAT

O inicio de sesión funciona, PWD funciona, e entón LIST colga ata que o cliente se rende ou pasa a outro modo de datos. Esa división é a sinatura: a conexión de control ao porto 21 está san, mentres que a conexión de datos constrúese desde un enderezo ou un porto que o outro extremo non pode acadar. Detrás dunha pasarela VPN que tamén fai NAT, o culpable habitual é unha orde FTP cuxa carga útil nomea un enderezo de túnel como 10.8.0.6. A tradución de cabeceiras nunca toca ese valor.

O que segue é de onde sae ese valor e que caixa ten permiso para cambialo.

O que se rompe é a carga útil, non o túnel

FTP pon o extremo de datos dentro do fluxo de control. No modo activo o cliente envía PORT co seu propio enderezo e porto, e o servidor marca de volta a esa tupla. No modo pasivo o servidor responde 227 cunha tupla, e o cliente marca esa no seu lugar.

As dúas formas levan o mesmo tipo de afirmación: conéctate a este enderezo, neste porto. Un dispositivo que só reescribe cabeceiras IP e TCP deixa a afirmación intacta, así que un extremo segue tentando acadar un enderezo que só existe ao outro lado dun túnel. A conexión de datos atópase despois de que a conexión de control xa fose declarada boa.

Tres modos, tres cargas útiles

A táboa de abaixo mostra a que lado se lle di que marque, e que pode facer un NAT que só reescribe cabeceiras respecto diso.

Lea a última columna como o que falla primeiro. No modo activo é o servidor quen marca a un enderezo privado; no modo pasivo é o cliente; con FTPS a carga útil é texto cifrado e a caixa intermedia ten aínda menos con que traballar.

Pón o auxiliar onde ocorre a tradución

En Linux a reescritura da carga útil faina o auxiliar nf_conntrack_ftp. Vixía a conexión de control, aprende o porto que se negociou, crea unha expectativa para o fluxo de datos e, nunha caixa NAT, reescribe o enderezo e o porto dentro da carga útil. Só axuda no dispositivo que traduce o enderezo do cliente. Cargalo no cliente, ou nun enrutador que só reenvía o fluxo, non cambia nada da sesión.

Estas tres ordes mostran se o módulo está presente, se está enganchado e se existe unha expectativa mentres hai unha sesión aberta:

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

Cargar o módulo non é o mesmo que enganchalo. Os núcleos desde 4.7 en diante veñen con net.netfilter.nf_conntrack_helper=0, así que o auxiliar espera unha regra explícita, por exemplo iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Se a lista de expectativas segue baleira mentres se intenta unha transferencia, o que hai que revisar é o enganche, non o módulo.

Modo pasivo: dígalle ao servidor que anunciar

O modo pasivo é máis fácil de facer determinista porque se lle pode dicir ao servidor que pór na resposta 227. En vsftpd iso é pasv_address, xunto con pasv_min_port e pasv_max_port; ProFTPD usa MasqueradeAddress e PassivePorts. Configure iso primeiro, xa que un enderezo anunciado correcto elimina a necesidade de reescribir nada nese lado.

Logo deixe pasar exactamente ese rango de portos pola pasarela, por exemplo -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, para que a regra coincida co que anuncia o servidor.

Os dous axustes teñen que coincidir. Un servidor ao que se lle di que anuncie 30000-30100 mentres a pasarela permite 40000-40100 falla do xeito menos útil: a conversa de control parece san e cada conexión de datos morre. Compare os números antes de depurar calquera outra cousa.

Dúas sinaturas de fallo, e que elimina FTPS

Un colgue en LIST apunta á primeira conexión de datos da sesión, onde tanto a reescritura de enderezo como a expectativa teñen que funcionar. Un colgue en RETR despois dun LIST que funciona apunta á propia transferencia, é dicir ao rango pasivo ou á MTU do túnel. Esa segunda sinatura non é un problema de carga útil, e os axustes do auxiliar non a arranxarán.

FTP sobre TLS elimina a carga útil que le o auxiliar. Unha caixa intermedia non pode reescribir un valor PORT ou PASV que non pode descifrar, así que quedan un proxy que remata TLS, un servidor que anuncia un enderezo alcanzable dentro dun rango limitado, ou un protocolo de transferencia distinto.

Unha orde breve de comprobacións

Traballa do síntoma cara a fóra. Confirma que LIST falla mentres PWD ten éxito, captura o enderezo dentro da carga útil PORT ou 227, e pregunta que dispositivo traduce ese enderezo. Engancha o auxiliar alí, observa a lista de expectativas durante unha transferencia, logo arranxa o modo pasivo no servidor e reflicte o rango na regra da pasarela.

Mantén o fallo da ruta de datos separado do fallo de transferencia masiva, porque levan a axustes distintos.