|
On Wed, 30 Nov 2005, Horms wrote:
> Mark de Vries <markdv.lvsuser@xxxxxxxxxx> wrote:
> > On Sun, 27 Nov 2005, Roberto Nibali wrote:
> >
> >> >> Is there an indication in RFC959 which states that this "behaviour" is
> >> >> legal as well for active FTP?
> >> >
> >> > no-one requires code to obey standards to sell it ;-(
> >>
> >> Well, vsftp is GPL and written by someone I happen to know even :). But
> >> it must be RFC conformant or else clients would not be able to properly
> >> interact with the server.
> >
> > As far as I understands the RFC leaves no room for a different src port
> > for the data connection. It's not fixed at 20 but should be 1 below the
> > controll port. Which is what ip_vs uses literally IIRC.
>
> Still, it would be harmless enough to add an option, passed
> as a module loading parameter to ip_vs_ftp, that allows an
> alternate port. It would be globabl, and obviously there are
> cases it wouldn't cover, but it would solve the problem at hand.
No. The point/problem is that the src port is unknown untill the server
actually connects to the client. The only way to fix this particular issue
is to create the connectio with an unknown src port (and then later fill
it in), as is done for the client src port in the passive case.
>
> I guess the remaining question is, should the problem at hand be solved
> in LVS.
True. That is the question. vsftpd is obviously operating in a non
rfc-compliant way (configurable) so ipvs is not at fault.
On the other hand I personally have never had any issues connecting to
servers acting like this. For my experiance it apears that most clients
don't care from which port the active connection originates from (or even
the IP) as long as it is to the correct port. And also all firewalls I
have been behind as a client don't care from which port the connection
originates from.
So we have servers disregarding strict rfc-compliance. We have firewalls
not enforcing rfc-compliant behaviour. And we have clients that don't
require rfc-complient behaviour. The only 'hop' en route that's beeing
pendantic is ip_vs. Now I'm not saying we should jump of a bridge just
bacause everybody else is... and I'm sure there are cases where this
behaviour will break. But if 'they' want to jump of the bridge then who
are 'we' to stand in their way?
Personally I can't think of a good reason why the fixed ftp-data src port
should be maintained. The only thing it's good for is predictable holes is
stateless firewalls...
Regards,
Mark
|
