Closed josephwinston closed 10 years ago
I don't have an ntlm-based proxy environment to test with, but looking at the cntlm options it looks like it can also act as a SOCKS5 proxy, which may work better than the http and https proxy options (use the socks5_proxy environment variable instead of http_proxy if you want docker-proxify to use SOCKS).
Unfortunately it will not be very easy to modify docker-proxify so that it will work with a proxy server running on the localhost (127.0.0.1) loopback interface. This is because the docker container will have its own loopback interface and so would route connections to localhost to the inner interface instead of the outer one.
However, looking at the cntlm manual, you ought to be able to get what you want by running cntlm to bind against a real IP address on the host machine (i.e. by running it in gateway mode with the -g
option - see the cntlm manual. If you do that, please be aware that unless you setup firewall rules to prevent other hosts from connecting to your cntlm instance, you may be exposing a security risk. You should be able to use iptables rules on the Linux machine to prevent access to it from other hosts, although it will be important that the container's IP address is able to access it.
An alternative occurs to me - you might find that if you just run cntlm within the docker-proxify container (i.e. by starting it after the docker-proxify docker run
command drops you to a shell), that could work without having to mess around with iptables rules.
I've now tested that running a proxy server within docker-proxify does work (I tested using squid3 bound to 127.0.0.1:3128 from within the docker-proxify container). I've updated the documentation to suggest this approach.
I'll add cntlm to my version, that in turn uses a cntlm configuration file that points to my ntlm proxy.
Thanks for the suggestion.
I run behind a corporate firewall using ntlm and often inside of a VM, which in turn is running cntlm for internet access. To make VM configuration easy, the *_proxy environment variables are of the form 127.0.0.1, which of course fails inside of the docker-proxify shell.