如何使用 Camel FTP 处理“主机尝试数据连接 xxxx 与服务器 yyyy 不同”错误？

Question

I'm trying to send a file to a third party ftp server (hosted by Amazon it would appear) with a Camel FTP Producer, and am having an issue where I am getting Writing File failed with: File operation failed... Host attempting data connection xxxx is not the same as server yyyy which I've not seen before.

The producer is configured to be in passive mode, and according to the logs at TRACE level, this is enabled. (Although the error message sounds like it would relate more to an active mode issue)

The yyyy IP address is one of those listed by nslookup for the target domain, so that bit makes sense. However, the xxxx IP relates to a different Amazon hosting server, and so I presume some sort of hand-off or load-balancing has been performed, and the FTP client doesn't like that.

Is there some way of configuring Camel FTP to allow this (I'm presuming this is a security feature), or should passive mode allow this anyway?

I have no influence with the ftp server provider, so unfortunately I can't change anything but my client options.

Thanks for looking!

Answer 1

After some digging, and grepping the source code for Apache Commons FTP, the message in question is caused by a validation in the client which checks that the passive mode connection is the same as the initial server connection.

Given that this appears to be a load-balanced system, the passive mode data connection is a different IP from the target IP, and this fails the validation.

It can be fixed using Camel FTP by creating a specific instance of the FTPClient and setting remove verification off.

FTPClient ftp = new FTPClient();
ftp.setRemoteVerificationEnabled(false);
registry.put("FTPClient", ftp);

and then referencing this object in the URI for FTP

ftp://user@host:21/path?password=xxxx&passiveMode=true&tempPrefix=part.&ftpClient=#FTPClient

Clearly, by disabling this remote verification test you are making yourself more vulnerable to the FTP data being redirected or intercepted and your data being sent somewhere you didn't intend, but I guess if you're worried about that you wouldn't be using still be using unencrypted FTP in the first place.