Closed qrkourier closed 1 year ago
Closing. I don't think we should invest in this any more. We should favor the linked issue you refer to. If you think this really needs to be completed, we can reopen this issue
This is actually a configuration issue. The tunneler is working as expected/intended.
Looking at the host.v1 configuration for the zedsDemoHttpHttpbin
service:
{
"allowedPortRanges": [ { "high": 80, "low": 80} ].
"allowedProtocols": [ "tcp" ],
"forwardPort": true,
"forwardProtocol": true,
"address": "172.17.0.1"
}
forwardPort
is enabled, and port 80 is the only port in the whitelist. The zedsDemoHttpHttpbin
would be usable by more clients if it set the server port to a specific value instead of attempting to forward the port that was intercepted by the client tunneler. e.g. a host.v1 config like this:
{
"protocol": "tcp",
"address": "172.17.0.1",
"port": 80
}
I noticed something unexpected when I was testing the Go
ziti tunnel proxy
. The problem was that the specified proxy port didn't match the allowed ports in the client config, but that constraint doesn't really make sense for an opaque proxy port. It still makes sense for a transparent proxy. For example, the allowed port was 80/tcp, and I tried to bind port 8080 and the client proxy always emitted an error.I expected to be able to bind an arbitrary TCP port to map to any named Ziti service the identity is authorized to dial. I found the dialing tunneler enforced a constraint that seems to have been intended for transparent proxies to ensure that only the expected traffic maps to the expected Ziti service.
The difference seems to be whether the mapping of port-to-service is expressed in the edge client config or as runtime configuration of the client itself. The explicit client-side config should have higher precedence.
Command to reproduce uses a ZEDS identity to dial the HTTPBin service on an illegal port