I have a service behind an API Gateway, and the API Gateway uses the Host information to identify a particular service. Therefore, when configuring intercept.v1, the corresponding domain name can only use the existing domain information, and I cannot use a custom domain like "*.ziti."
I want it to use the domain name configured in the host.v1 parameter. Although I am intercepting with "test.ziti," I hope that when accessing the service, the request carries the Host header information configured in host.v1 as "server1.xxx.local."
Alternatively, I could add a headers configuration option to the host.v1 configuration to solve this issue.
Of course, I can deploy the router or tunnel behind the API Gateway or Ingress, so the situation of selecting a route based on the Host header information would not exist.
OpenZiti is a secure connection from client to server. It does not deal with layer 7 whatsoever so when your HTTP client requests test.ziti, that HTTP payload will traverse the overlay with Host: test.ziti. There is no mechanism to affect this HTTP (layer 7) host header.
You could choose to deploy a new API gateway on on internal IP address and map the new OpenZiti host and "trust" your internal, private network... Or as you said, deploy OpenZiti behind the gateway.
Personally, if possible, I'd recommend you deploy adjacent to the service and offload to 127.0.0.1 towards your service (the "Zero Trust Host Access" model of deployment). That way you reduce your trusted network space to the pod/os but I realize that's not always the most practical way of doing things. 
1 Like