I have a client in aws in its account and an application in aws in another account. I am trying to make the client talk to the server over ziti network.
These are the steps I have taken so far -
Both client and server are registered as endpoints and are green in the console
Both client and server have ziti-edge-tunnel running
edge router policies allow the client and server endpoints
A service is created with a config of “endpoint hosted”, intercept added for my-domain/443/TCP and server endpoint selected as destination with a diff forward address and port (my-internal-domain/8443/TCP)
AppWAN is created allowing client and server to talk to each other.
If I do resolvectl query my-domain on the client, it does resolve to 100.64.xx.xx, so I am assuming there is no problem with the ziti-edge-tunnel setup and its using systemd-resolved as expected.
Quick note… as I thought to share a few of my learnings.
When you connect to a zitified endpoint… you need to dial a service with an identity that has been enrolled on the machine you are making the call from.
A great example of this is the following zitified curl command that is written in golang.
Hence… what you are experiencing is an expected result… because you cannot use the default curl command to connect.
To better understand this… try to get the golaong curlz example to work…
There are also a lot of other golang examples that are useful to work through… zping, zcat, reflect etc
I have found that these examples fill in a lot of the missing gaps between they typical approach today… versus… how it’s done over a ziti overlay.
Ohh… and make sure you do the zitified ssh example… this requires a tunneller to be installed to get to work… which also provide another way to connect.
You need to download the tunneler from here to install on the server before you can run the zitified ssh client
For the first phase I want to stay away from SDKs and only use tunnelers. The idea is to achieve zitification without making changes to application first, before using SDKs and making applications ziti aware.
I will definitely try the zitified ssh. Although I did try installing a simple nginx server on the other end ( diff endpoint ) and that works over curl, but I am not able to make my custom service work.
Makes sense… and can see where you are coming from.
I am not 100% sure… though… I believe you need to zitify at least one application to use a tunneller application…
You can work around this by using a zitified reverse proxy… that you put in front of the normal app/server… which then creates the zitified end point.
You can then use a tunneller to access this zitified end point… which will work if its a http server… but not if its an API… as the client will need to use the ziti SDK to access the end point.
To resolve this… you can create another zitified reverse proxy server that takes this ziti endpoint… and turns it back into a normal service.
This is how I have found out how to get started without making any code changes… which then provides a dark moat around your backend service.
I created this in gloang… using the golang SDK… its not that much work to do… about 20-30 lines of code for each reverse proxy server.
It was my bad ( incorrect Route 53 record for my-internal-domain ). Now its working as expected where client can connect to the server without any SDKs involved.
Clarification to your statement, “I believe you need to zitify at least one application to use a tunneller application”.
Within Ziti (today) there is the Edge and Fabric:
Edge: Secure, Zero Trust entry point into your network (identity-based authorise, authenticate, encrypt) via SDK or tunnels
Fabric: Scalable, pluggable, geo-scale routable mesh network overlay, with smart routing and dynamic healing features
Any application which operates over the OpenZiti, private overlay needs to have the edge to the onramp. This can be application-aware, i.e., SDK embedded, or app-unaware, i.e., tunneler on host doing interception. The edge is required at both source and destination in any mixture with services hosted anywhere.
As av-dev says, that can be tunnelers on both sides.
