On 13/12/17 04:51, Sticher, Jascha wrote:
Hi,
we're currently upgrading our proxy environment to squid 3.5.23 (Debian
Stretch) and would like to use the native FTP proxy feature to replace our old
FTP proxy solution (frox).
Due to some design choices, we have a proxy hierarchy for HTTP as well as FTP
traffic. Is there a way (yet) to tell my first squid instance to use another
squid as a forward proxy with native FTP?
IIRC, the cache_peer directive always uses HTTP requests, so this seems as a
dead end.
The FTP traffic arriving at Squids ftp_port is converted from a stream
of FTP messages to a stream of HTTP messages for handling.
AFAIK those resulting HTTP messages can be routed through a cache_peer
same as any other HTTP traffic. BUT at very least the peer needs to also
have the same "native FTP" implementation to successfully convert them
from HTTP back to FTP native messages on the outgoing server connections
at the other side of the cache hierarchy.
There may be other internal state checks on the HTTP messages to make
them get the "native FTP" conversion on outgoing. So YMMV.
If the peer delivery does not work you may be required to do the same
workaround SSL-Bump sometimes requires. Do allow the front-end Squid to
re-FTP the traffic to the appropriate server then intercept it
independently into the backend with its own ftp_port accepting the
"native FTP" coming out of the frontend.
FYI: I do know there are conversion issues with FTP <-> HTTP
authentication recently uncovered and not yet resolved. So if you need
proxy auth at all staying with Frox would be better for now.
Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
