背景

ELBv2的TCP监听器采用FULLNAT的负载模式,将客户端发来的请求IP包的源地址和目的地址都替换掉。

一、FTP两种场景分析

FTP业务的主动模式中,服务端会直接向ELB发起新数据连接,这种模式的流量无法送到客户端,导致ELB不支持FTP主动模式。 image.png

FTP 被动模式下,先是client经ELB发起FTP控制面的流量到server,然后server收到客户端的PASV请求后,会告诉客户端数据连接的IP和端口,客户端收到后会和这个IP和端口建立连接,这个连接的流量不再经过ELB。 image.png

由于数据连接的源IP是客户端的IP,和控制面的源IP(ELB FULLNAT之后的IP)不一样,会导致数据面认证失败,从而导致ELB负载的FTP被动模式下数据流量不通,导致被动模式流量连接出现“425 Security: Bad IP connecting.”报错。

二、解决办法

方法1、修改FTP server的校验规则

修改FTP server的一个配置: vim /etc/vsftpd/vsftpd.conf

pasv_promiscuous=YES

重启server: systemctl restart vsftpd

https://www.cnblogs.com/kuliuheng/p/3209744.html

方法2、通过ELB的源地址透传功能获取真实IP

FTP server可以利用TOA模块来获得ELB流量的真实IP,通过这个IP去校验被动模式下绕行的数据面流量的source_ip。

TOA插件配置:https://support.huaweicloud.com/usermanual-elb/zh_cn_elb_06_0001.html

两种方法的数据面链接都还是绕行ELB的,这一点没法改。

三、ELB负载FTP被动模式验证过程

服务端使用vsftpd起FTP服务: 4.png

ELB私网地址是10.0.0.189,TCP监听器的监听端口为8000,ELB实例信息截图: 3.png

客户端向ELB地址10.0.0.189 的8000 端口发起链接: 5.png

对应的客户端的抓包结果:可以看到client(10.0.0.108)在数据面主动链接了后端server(10.0.0.175),但是因为鉴权失败,导致数据没有发过来。 1.png

Server收到的client的数据面的请求: 2.png

综上可以看到客户端经ELB和服务端的控制面通信正常,但数据面通信失败。

其他思考 当前的ELB产品都是端口粒度的转发,IP粒度的负载均衡是不是功能更强大?有必要吗?

附件ftpserver rpm和抓包文件