Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NO_PROXY does not work with DNS name but with IP #3401

Closed
LSChyi opened this issue Feb 26, 2020 · 6 comments
Closed

NO_PROXY does not work with DNS name but with IP #3401

LSChyi opened this issue Feb 26, 2020 · 6 comments

Comments

@LSChyi
Copy link

LSChyi commented Feb 26, 2020

What version of gRPC are you using?

v1.23.0

What version of Go are you using (go version)?

go version go1.13.6 linux/amd64

What operating system (Linux, Windows, …) and version?

PRETTY_NAME="Debian GNU/Linux 10 (buster)", actuall it is the docker image golang:1.13.6-buster.

What did you do?

In my Kubernetes cluster, I set the env HTTP_PROXY to an HTTP proxy (a tinyproxy pod) and set NO_PROXY with the domain name in Kubernetes to bypass these traffics on gRPC clients.

For example, I set up a service not-proxied in the default namespace, and if I set NO_PROXY to .default.svc.local.cluster or not-proxied.default.svc.local.cluster, the dial address in client is not-proxied.default.svc.local.cluster, the gRPC call to these services still uses the HTTP proxy. Only If I set the NO_PROXY to the cluster IP of that service, these gRPC traffics will not use the HTTP proxy.

What did you expect to see?

The gRPC call to those services in NO_PROXY should not use the HTTP proxy.

What did you see instead?

The gRPC call to those services in NO_PROXY still uses HTTP proxy for I can get proxied logs from my HTTP proxy.

@menghanl menghanl changed the title NO_PROXY does not work with service DNS in Kubernetes but with cluster IP NO_PROXY does not work with DNS name but with IP Feb 26, 2020
@menghanl
Copy link
Contributor

Proxy is currently implemented as a dialer, so it doesn't see the hostname before name resolution.

A solution would be to also pass the un-resolved name, and check that against NO_PROXY.

For now, as a workaround, if you want to disable proxy for one ClientConn, override its dialer WithContextDialer.

@dfawley dfawley added the P2 label Feb 27, 2020
@danmux
Copy link

danmux commented Mar 29, 2020

We are hitting this same issue, I can submit a PR to do as @menghanl suggests.

@danmux
Copy link

danmux commented Mar 29, 2020

There is a recent change related to #3411 that may make this less important / needed.

@menghanl
Copy link
Contributor

menghanl commented Apr 3, 2020

To add more details:

We want to support proxy at two levels:

  • on the server name, before name resolution
  • on the IP addresses, after name resolution

With the current set of APIs, there's no easy way to support both.
To do this, we will need to design another proxy API.

There was an old PR (#1095) that does this.

@danmux
Copy link

danmux commented Apr 6, 2020

Makes sense.

We have worked around this by doing the env var detection up front. If it is not conducive to the round robin balancing we fall back to single direct host with passthrough - to prioritise honouring NO_PROXY

@dfawley
Copy link
Member

dfawley commented Nov 28, 2022

This is low enough priority that I'm going to close it for now. The dial option to disable the proxy can be used instead as a workaround.

@dfawley dfawley closed this as not planned Won't fix, can't repro, duplicate, stale Nov 28, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants