Socks5 proxy support #17754
Comments
|
👍 +1 to this enhancement request! Just wanted to add some findings here and a use-case to clarify an example networking setup. My team has found that running Terraform inside a docker container is best in order to ensure every DevOps engineer is using the right version of Terraform for any given infrastructure as code repo. This has the benefits of removing hard dependency on Terraform by just relying on docker, and insulating against Terraform template syntax deprecations and future API breakage (Terraform is still Here is a diagram of the setup:
The way to set this up is to do the following: Simple proof of concept, but very useful! This can be used or abused so far in Terraform via However, if you need output from a Current Terraform ProblemHowever, Terraform itself has problems when combined with the standard proxy environment variables: Then, Terraform appears to hang indefinitely! Note: This behavior is with If you were curious to run with debug output, by setting: Then, you would run into errors such as: This error repeated many times, as Terraform's I tested one last connection using This indicated success in that So, this test seemed to indicate a problem with the GoLang Terraform binary itself! It could also indicate some issue in GoLang, or the specific library or connection method that it Terraform is using. So, although I feel like we have made 99% progress towards solving the Docker container to VPC tunneling issue, the problem now is just with the Terraform tool itself. This is most likely due to the known issue in Golang's The good news is that whenever this issue is solved upstream in Golang, we should be able to use a future version of Potential Path ForwardThere is light at the end of the tunnel! (Pun intended) There is an upstream bug in Golang to ask for |
…P alias on lo0 every reboot (For use with Docker for Mac) Use case: Docker container == socks5h:// ==> Alias IP of macOS Host running SSH Tunnel => Bastion Host See diagram: https://gist.github.com/trinitronx/6427d6454fb3b121fc2ab5ca7ac766bc References: - [user-defined networks](https://docs.docker.com/network/bridge/##differences-between-user-defined-bridges-and-the-default-bridge) - [Docker forum thread: Connecting docker container to macOS Host](https://forums.docker.com/t/accessing-host-machine-from-within-docker-container/14248/13) - [Terraform enhancement request for SOCKS5h support and Explanation of Use Case](hashicorp/terraform#17754 (comment))
|
@jbardin, I would like to know if there any progress on this issue? :) |
|
Hi @0just0, Any updates on the issue would show up referenced here. Thanks for detail @trinitronx. There's really 2 separate problems here. The original issue is to add socks5 support to the provisioner, which is possible for ssh and only blocked for now because of other core working being done at the moment. This should be fairly straightforward since that tcp connection is controlled by terraform itself, and limited to a single process. The second http proxy issue which you highlighted, which is the more difficult issue, is that terraform can't control all http connections from every sdk. While the core of terraform can control its http clients for various internal usage (downloading modules, fetching provider binaries, provisioner communication), there's no way to add that support to all possible dependencies, nor is there a way to force providers to use the proxy if it's possible at all. The only complete solution for socks5h would need to come from upstream. |
|
@jbardin : Thanks for the info! Good to know it's possible for Regarding the Golang
So it's possible to do this in a way similar to the |
|
Though I haven't verified the code, k8s is most likely able to do it with kubectl because it communicates only with kubernetes from the cli process. If they have control over all the clients and their name resolution, then situation is far easier. As mentioned earlier, terraform can only directly control the clients used in the main binary. The providers would each have to independently setup their own clients to use the custom proxy (which may not be possible with all SDKs, though the overall situation is improving). It's not unsurmountable but it is a large task to cover over many independent codebases. Because larger organizations tend to run terraform in automation, the infrastructure can usually be built to accommodate terraform, rather than trying to work around limitations in the infrastructure, so this isn't something that is frequently encountered. I understand you may have a use case for this type of proxy, but since adding socks5 proxy support to the provisioner and adding socks5h support globally are quite different, this particular feature request is going to strictly be for provisioners. Feel free to open a separate feature request for full socks5h support though, with the info you've provided here. |
|
Just wanted to circle back on this because I ran into another use case today for using I did some research today and found that some upstream GoLang changes regarding SOCKS5 have happened since this original issue was posted. So far it looks like this is intended to replace the old implementation, but still supports only At first glance, it looks like as long as the proxy URL begins with Next, this gets split via So it appears to be aware of FQDN / DNS names now... just without Testing |
|
This feature would be incredibly helpful when configuring services that run in VPC and are only reachable from within the VPC (e.g. k8s services). I tried to I believe this is were EDIT: The command that I used: |
|
I use proxychains-ng cd /usr/local/etc proxychains4 terraform init |
|
I was able to start proxying via socks5h by starting a sock5 proxy (tor in my case) then updating my /etc/hosts file as well as setting some ENV variables. I've verified Terraform is in fact using the proxy by monitoring iptables rules and tcpdump. This consistently works for me. Hope this helps. tor --HTTPTunnelPort 127.0.0.11:80
export ALL_PROXY=socks5h://127.0.0.1:9050
export HTTPS_PROXY=socks5h://127.0.0.1:9050
export HTTP_PROXY=socks5h://127.0.0.1:9050Add to 127.0.0.11 socks5h |
|
Greetings from the future! I'm a time traveler from the year 2022. SOCKS5 support would be great, and I'm unable to compile proxychains-ng on an M1 CPU. |
|
Contrary to what the documentation may lead us to believe, this already works. https://developer.hashicorp.com/terraform/language/resources/provisioners/connection#connection-through-a-http-proxy-with-ssh shows how to use an HTTP proxy. Just set the scheme to "socks5". |
Fixes hashicorp#17754, surprisingly.
Fixes hashicorp#17754, surprisingly. `golang.org/x/net/proxy.FromURL` (which Terraform uses to add support for HTTP and HTTPS) supports socks5 out of the box: https://cs.opensource.google/go/x/net/+/refs/tags/v0.15.0:proxy/proxy.go;l=91
Hmm... maybe something has changed since years ago? It would be interesting to check if also |
|
If you check out the PR generously provided by @sorenisanerd, it links to the code in the go library that seems to indicate that socks5h is also supported at some level. I am not an expert on this so it would still need to be verified. |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Hi, I'm wondering whether you're planning to add support for socks5 proxy in terraform like Packer has?
It would be very useful to have this feature cause right now I'm struggling with running terraform behind our company's proxy and have to use it through ssh tunnel and bastion host.
I was trying to add socks5 support by myself but faced several issues:
but when I built a binary I got this error -
So it looks like terraform can't get new properties from configuration.
I also added almost identical code from packer source to "communicator/ssh/communicator.go"
The text was updated successfully, but these errors were encountered: