proxyDial not compatible with domainMatchers for NO_PROXY settings. #7779
Labels
Comments
|
Hi @akats7, This looks related to the #7556 . Earlier we used We've now switched to We're actively working on the fix. |
|
Thanks @eshitachandwani, is there any known timetable for the fix? |
|
Hey, it might take a few weeks for the fix. But for the time being, you can try manually specifying |
bogdandrutu
pushed a commit
to open-telemetry/opentelemetry-collector
that referenced
this issue
Nov 4, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This is related #11537 and [this grpc issue](grpc/grpc-go#7779), to reiterate there is a bug in the grpc-go NewClient that makes the way the hostname is resolved incompatible with the way proxy setting are applied. Due to this domain based NO_PROXY setting do not work for grpc connections. They are working on a fix in the grpc library but until then it seems like it might be a good idea to revert to using DialContext instead of NewClient. If there's a workaround for this that anyone is aware of that could be suitable as well, the most clear one of using passthrough doesn't work since we sanitize the endpoint. <!-- Issue number if applicable --> #### Link to tracking issue Fixes #11537 <!--Describe what testing was performed and which tests were added.--> #### Testing I added some logging where the proxy setting are evaluated to show the behavior. **DialContext** ______ InMatch host : otel*******</DOMAIN-NAME/> m.host : </DOMAIN-NAME/> hasSuffix : true m.matchHost : true ______ **NewClient** ______ InMatch host : 10.*.*.*.* m.host : </DOMAIN-NAME/> hasSuffix : false m.matchHost : false ______ --------- Co-authored-by: Yang Song <[email protected]>
djaglowski
pushed a commit
to djaglowski/opentelemetry-collector
that referenced
this issue
Nov 21, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This is related open-telemetry#11537 and [this grpc issue](grpc/grpc-go#7779), to reiterate there is a bug in the grpc-go NewClient that makes the way the hostname is resolved incompatible with the way proxy setting are applied. Due to this domain based NO_PROXY setting do not work for grpc connections. They are working on a fix in the grpc library but until then it seems like it might be a good idea to revert to using DialContext instead of NewClient. If there's a workaround for this that anyone is aware of that could be suitable as well, the most clear one of using passthrough doesn't work since we sanitize the endpoint. <!-- Issue number if applicable --> #### Link to tracking issue Fixes open-telemetry#11537 <!--Describe what testing was performed and which tests were added.--> #### Testing I added some logging where the proxy setting are evaluated to show the behavior. **DialContext** ______ InMatch host : otel*******</DOMAIN-NAME/> m.host : </DOMAIN-NAME/> hasSuffix : true m.matchHost : true ______ **NewClient** ______ InMatch host : 10.*.*.*.* m.host : </DOMAIN-NAME/> hasSuffix : false m.matchHost : false ______ --------- Co-authored-by: Yang Song <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi all,
The http2_client uses proxyDial which uses the net/http package's ProxyFromEnvironment function to determine whether to apply proxy settings to the connections. The ProxyFromEnvironment function parses the NO_PROXY string and uses a matcher interface to compare the address against the ips and domains in the NO_PROXY string. However, it looks like only the ip address string is passed to the proxyDial function instead of the resolver.Address which includes the hostName.
Due to this, domain based NO_PROXY settings do not seem to be applied as all matching is done directly against the IP.
What version of gRPC are you using?
1.67.1
What version of Go are you using (
go version)?1.23.2
What operating system (Linux, Windows, …) and version?
AmazonLinux
What did you do?
If possible, provide a recipe for reproducing the error.
What did you expect to see?
PROXY setting to remain unset when including target domain in NO_PROXY
What did you see instead?
HTTPS_PROXY set even when target is included in NO_PROXY
The text was updated successfully, but these errors were encountered: