-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
filter_chain_match does not apply to dynamic_forward_proxy HTTP targets #15348
Comments
cc. @lambdai |
i suspect the l4 original address is what localhost is resolved to. The 192.168 ip in the curl is not particiing the L4 address match. I can give it a try and update later today |
@lambdai thanks! I was able to confirm your suspicion by doing the following:
Can you advise how to filter the destination IP CIDRs when the Envoy cluster acts as a |
To add more context, I would like to add what is my final goal: I want Envoy to forward HTTP requests that are resolved to a private subnet destination IP via one dynamic forward cluster, and all the requests that resolve to public IP subnets via another. |
@aSapien Thank you for the update! I don't see the solution that you can combine multiple httpfilter/cluster/router to reach your goal. Other smarter people can add. I probably choose one from a) or b)
b) Use dynamic forward cluster but different behaviors upon ip pool. |
One more thing I just tried is using the I was able to match the destination IP on the route_config:
internal_only_headers: [] # TODO: Set intrnal headers
name: local_route
virtual_hosts:
- name: local_service
domains:
- "127.*"
routes:
- match:
prefix: "/"
direct_response:
status: 200
body:
inline_string: |
Filter match! However, since |
@lambdai thank you for the suggestions! I'm optimistic again :)
Can you please point me to any docs that would describe the process of implementing a new filter and how I can consume the destination IP from it?
Is it possible to configure the target IP "filter" from within the |
I don't have the quick answer. You probably need to forge the existing https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/http/dynamic_forward_proxy/proxy_filter.cc |
The upstream network filter within cluster: https://github.com/envoyproxy/envoy/blob/main/api/envoy/config/cluster/v3/cluster.proto#L963 |
@lambdai I was thinking about this idea: Create 2 listeners:
Then configure the Will the |
This generally works but there is a critical missing piece. To complete the last piece, you can
|
@lambdai thanks for explaining. I see now that there's quite the missing piece there.
Wow, I was reading through this blog post assuming it might help me understand, but I'm not very experienced with
From what I understand, in my use case a listener (listener2) will be able to act as a router/gateway for outgoing traffic from I really need the I think that restricting the destination IPs is an important feature in forward proxies. It seems like (2) will require some wiring/configuration support on |
Yeah... It is somewhat overkill. |
+1. It can be done by adding functionality in dynamic_forward_proxy cluster, or by chaining the Both require a few changes in dynamic_forward_proxy. It's up to you whether you want to create a dedicated issue or CC more people in this one. |
Adding @mattklein123 @alyssawilk, the code owners of Dear code owners, I would love to have your blessing on the idea of enabling the |
Is there a TL/DR summary of the changes you would like to see? |
The idea is to have an ability to configure an ACL to filter the target upstream of a request coming out of the For example: curl http://<envoy_ip>:10000 http://<allowed_ip>:<allowed_port> # Should pass
curl http://<envoy_ip>:10000 http://<disallowed_ip>:<or_allowed_port> # Should not pass
curl http://<envoy_ip>:10000 http://<domain_resolving_to_disallowed_ip> # Should not pass The cluster configuration could look as follows: clusters:
- name: dynamic_forward_proxy_cluster
connect_timeout: 1s
lb_policy: CLUSTER_PROVIDED
cluster_type:
name: envoy.clusters.dynamic_forward_proxy
typed_config:
"@type": type.googleapis.com/envoy.extensions.clusters.dynamic_forward_proxy.v3.ClusterConfig
dns_cache_config:
name: dynamic_forward_proxy_cache_config
dns_lookup_family: V4_ONLY
+ upstream_filters:
+ - upstream_filter_match:
+ prefix_ranges:
+ - address_prefix: 10.0.0.0
+ prefix_len: 8
+ filters:
+ - direct_response:
+ status: 403
+ body:
+ inline_string: |
+ Forbidden
+ - upstream_filter_match:
+ prefix_ranges:
+ - address_prefix: 0.0.0.0
+ prefix_len: 0
+ filters:
+ - proxy_pass: {} |
Yeah I think it would be a good fit, we'd be able to couple this with the unified matching and composite filters to provide per match filter application |
@mattklein123 Of course, I would always prefer the general solution as long as it provides the building blocks to compose for a specific use-case :) @snowp I see that there hadn't been much activity in #10455 recently. What can be done to push it forward? |
I haven't had the time to work on it in a bit, though if someone wants to pick it up I would happily review. There is still quite a bit of work left, I had #13095 open as a POC of integrating the filter manager with the router, which opens up for making upstream HTTP filters configurable via the API. |
I would pick it up but I'm afraid I need to catch up on my cpp first 😅 |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
Title:
Prefix ranges for destination CIDR do not match
Description:
When using a filter chain match for destination using
prefix_ranges
(for example)192.168.0.0/16
the filter chain is not found and the connection is closed.Repro steps:
Start a standard envoy docker container with the command and config (provided below). Once running, try to perform a request and match on the filter, reaching the
dynamic_forward_proxy
cluster.Request command:
The expected result is to have a "Filter match!" response (as defined in the
direct_response
route), but no response is returned (curl: (52) Empty reply from server
) and the log shows that there was no matching filter.Relevant log line:
Envoy docker command:
docker run --rm -it -v $(pwd)/config.yaml:/config.yaml \ -p 9901:9901 \ -p 10000:10000 \ envoyproxy/envoy:v1.17-latest \ -c /config.yaml --log-level debug
Admin and Stats Output:
*/stats*: (Click to expand)
*/clusters*: (Click to expand)
*/server_info*: (Click to expand)
Config:
*Logs*: (Click to expand)
The text was updated successfully, but these errors were encountered: