Configuring the http example that connects to ZitiMobileEdge client

Here is the vision… I want to setup the http example… and then connect to it using the ZitiMobileEdge app on my mobile.

What I am doing is to create a hypothesis of all the configurations that I believe I need before I execute it… I have enough understanding now to start to be a bit more specific than when I first started

This way… I can uncover what I don’t understand in more detail… and reduce the chances of making a stupid mistake… it also helps me improve the accuracy of what I am doing. It was pretty scattered initially…

I have already tested the installation of the controller with the reflect example.

Step 1. create a env file

I have setup the controller to use port 1280 and 6262

service_name=httpz
client_identity="${service_name}“Client
server_identity=”${service_name}"Server
the_port=1280

Step 2 make the env file executable

I learnt this the hard way

chmod u+x httpz.env

then run the env file to load the variables into the bash profile

Step 3 delete exiting bind & dial policies

lots of pain here if you dont do this :slight_smile:

ziti edge delete service-policy allbind
ziti edge delete service-policy alldial

Step 4 create new service and bind & dial policies

this is the config for the host
ziti edge create config “${service_name}”-host.v1 host.v1 ‘{“protocol”:“tcp”, “address”:“localhost”,“port”:’"${the_port}"’, “listenOptions”: {“bindUsingEdgeIdentity”:true}}’

this is the config for the client
its interesting that there is a port range for the client… it would be useful to further expand on this
ziti edge create config “${service_name}”-client-config intercept.v1 ‘{“protocols”:[“tcp”],“addresses”:["’"${service_name}.ziti"’"], “portRanges”:[{“low”:’"${the_port}"’, “high”:’"${the_port}"’}]}’

this creates the service for the client and host
ziti edge create service “${service_name}” --configs “${service_name}”-client-config,"${service_name}"-host.v1

this creates the bind and dial policies
ziti edge create service-policy “${service_name}”-binding Bind --service-roles ‘@’"${service_name}" --identity-roles ‘#’"${service_name}"‘ServerEndpoints’
ziti edge create service-policy “${service_name}”-dialing Dial --service-roles ‘@’"${service_name}" --identity-roles ‘#’"${service_name}"‘ClientEndpoints’

Step 5 create and enroll server identities

ziti edge create identity device “${server_identity}” -a "${service_name}"ServerEndpoints -o “${server_identity}”.jwt

ziti edge enroll “${server_identity}”.jwt

Step 6 create and enroll clent identities

I left this last as you have 5 min to enrol…

ziti edge create identity device “${client_identity}” -a "${service_name}"ClientEndpoints -o “${client_identity}”.jwt

copy jwt file to local machine
scp -i zzzz.key opc@…:/home/opc/go-demo/simple-http.go /local_user/files

Once created… download the jwt to my machine, email it to my phone and paste into the ZitiMobileEdge application

Thanks, let’s use this one big thread to get your http example running. My first question, which http example are you looking to setup? Are you looking to do this from “tunneling app to tunneling app”? (undoubtedly the easiest way to start)

My favorite http example to start with is super easy. It just changes the resolved IP address. There’s a bunch of ways to do this but I start out by visiting “eth0.me”. Without OpenZiti you get your default ip address. But once you make the proper service, with OpenZiti you get the ip of whatever machine has terminated the actual traffic. That’s a simple one to start with. It’s also easiest to start with “tunneling app to tunneling app”. So let’s start there too. We’ll start with browser on mac/windows first using a Ziti Desktop Edge, then we’ll add a new identity - a mobile device.

FWIW - If you setup the ZAC (ziti admin console) you can just use your phone to scan the QR code. Which I see now the icon isn’t showing up in the ZAC. Where this red arrow points is actually a clickable link. (a bug we need to fix)

Then you can just use ‘add identity’ for your mobile (it’s a bit easier)

I’ll try to find some time, late today my time or early tomorrow to tidy this up into a little package for you.

1 Like

This is the example

I have everything setup for the server… and now need to setup the client on the Zit Mobile Edge app

PS… given you comments re the app… I am assuming that the ip of the controller is embedded in the jwt file
is this correct?

Oh - ok excellent. I’ll use that as input to the video showing how I’d do it. the ip of the controller - technically the DNS name more likely is indeed baked into the jwt - which is also a cryptographically signed document by the controller. The other post you have shows my controller dns name in the document after being parsed.

here: Debugging the Ziti Mobile Edge tunneller - #5 by dovholuknf

Ok I’ve had a moment to prepare some screen caps/steps for you. Here’s how you do it…

Prerequisites

  • You have a ziti overlay network deployed
  • you’ve made two identities - one that will be the ‘server’ and one that will be ‘a client’
  • you’ve enrolled the ‘server’ identity and have the .json file locally for use with the golang sample

Create the ONE config needed

You will only need an"intercept.v1" config for this - since you are using the golang sdk and “listening” on the ziti overlay network, you are NOT offloading traffic at your server. This means you only need “trust” inside your application - that’s amazing! Since you’re using a tunneling app at the client side, you will need the “intercept.v1” config. Let’s make that config now:

ziti edge create config golanghttp-intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["golanghttp.zitified"], "portRanges":[{"low":1234, "high":2345}]}'

Now let’s inspect what we’re saying here. We’re telling the overlay that you want a config, named golanghttp-intercept.v1 which is of type intercept.v1 that will allow a tunneling client to get a private DNS intercept named “golanghttp.zitified” on their device and we’ll allow a port range (i did that for fun) of ports 1234 through 2345

Create the service

Now you have the one config you need - now make the service

ziti edge create service golanghttp --configs 'golanghttp-intercept.v1'

Here we are instructing ziti to make a new service called “golanghttp” and to use the one config we just made “golanghttp-intercept.v1”

Authorize the “server” identity

You have already enrolled an identity that you want to ‘be the server’. Now you need to authorize the identity to ‘bind’ that service using a serivce-policy:

ziti edge create service-policy golanghttp-bind-policy Bind --identity-roles '@http.server.identity' --service-roles '@golanghttp'

We are telling ziti to make a service-policy named “golanghttp-bind-policy” of type “Bind” and authorizing ONLY the identity with the name “http.server.identity” to bind the services with the name “golanghttp”

Authorize the “clients” to Dial this service

Now we want to make it so identities can access this service. We do that by making a ‘dial’ service-policy:

ziti edge create service-policy golanghttp-dial-policy Dial --identity-roles '#http-clients' --service-roles '@golanghttp'

We’re telling ziti to make a service policy named “golanghttp-dial-policy” of type “Dial”. Allowing any identity which has the role of “http-clients” to dial the specific service named “golanghttp”

Wait a second - a ROLE???

That’s right - we don’t want to have to update this policy everytime a new identity wants access. That’d be horrible. So here we have used a ROLE instead. A role is an attribute added to an identity. Your mobile identity probably doesn’t have this role yet - let’s add it:

ziti edge update identity ${your.mobile.identity.name.here} -a "http-clients"

Is that it?

Yep. Assuming your mobile identity was already enrolled - by the time you read this you’ll probably notice a new service shows up on your device… Here’s what it looked like on my mobile when i did it:

You can see I now have a “cdaws-mobile” identity and it has access to one service. Now I can go to my browser and go to: http://httpserver.zitified:1234/add?a=4&b=7 and get a response from the zitified server in my tunneling app…
image

Conclusion

And that’s all there is to it… Since this is a discourse post - not a actual writeup, i might have messed up a step here or there or glossed over something - but I think I got all the steps correct.

You should be able to replicate the same… And next time you make an identity - since we used that roleAttribute idea - you can just make the identity with the attribute predefined and give that identity access to the same http server. Like this:

ziti edge create identity user newUser2 -a "http.clients"

That identity now will be authorized to use the http server you setup. neat stuff - right??? :slight_smile:

2 Likes

Awesome… the explanation really help… and it is very cool.

will update when I work through it all

I am working through this and noticed two things

#1… what happens if you create a host policy if you don’t need it

I have since deleted this… though… would it make any difference?

#2… the service policies did not have a service-role

This is interesting… because I used the following script to do this… I will have to play around with this a bit more…

ziti edge create service-policy “${service_name}”-binding Bind --service-roles ‘@’"${service_name}" --identity-roles ‘#’"${service_name}"‘ServerEndpoints’

what is the purpose of the service-roles.
what is the difference between identity-roles

I have a general understanding of different roles… as you can create profiles that can be reused… though are unsure of why they are distinguished between service and identities

how do you create a new role

It appears that roles are automatically created… ie… as you add a tag… its added to the list of roles available.

is this correct?

ok… got the difference now

the service policy maps the identity to a service

two service policies are required

bind… to link the server identity to the service
dial… to link the client identity to the service

getting there :slight_smile:

quick update… still getting stuck on this… and have made all of the changes mentioned above

I looked into the packet tunnel log on the Ziti Mobile Edge app and noticed the following

connect timeout… no suitable edge router

ziti dial failed: operation did not complete in time.

I dont know if this was related to the issue with getting the “green” light on the tunneller… but that bit is working now.

So… the question I have now… is how to debug this further…

  1. I have tested that the golang server is running.
  2. I have enrolled the identity on the mobile app
  3. the VPN is connected

However… when I go to the following URL… nothing happens

https://httz.ziti:1280/add?a=4&b=7

What else can I do to debug this… and narrow down where the problem is?

I did find something in the instance-20220317-1005.log which is the name of the machine

if this is the problem… what do I need to do to fix it… as I don;t really know how this happened…

maybe I need to just start from a fresh start again :slight_smile:

[15040.295] INFO : http: TLS handshake error from 168.138.12.254:48404: EOF
[15040.311] INFO : http: TLS handshake error from 168.138.12.254:48406: EOF
[15121.807] INFO : http: TLS handshake error from 168.138.12.254:48418: remote error: tls: bad certificate
[15340.302] INFO : http: TLS handshake error from 168.138.12.254:48458: EOF
[15640.299] INFO : http: TLS handshake error from 168.138.12.254:48500: EOF
[15940.297] INFO : http: TLS handshake error from 168.138.12.254:48538: EOF
[16181.253] INFO edge/controller/handler_edge_ctrl.(*removeTerminatorHandler).RemoveTerminator: {routerId=[wYXvHOJa9x] serviceId=[B0GNX-e-H] terminator=[2eJG] token=[5b73f46d-51af-402c-9a6d-59b7947ee7eb]} removed terminator
[16181.254] ERROR edge/controller/handler_edge_ctrl.(*baseSessionRequestContext).verifyTerminator: {operation=[remove.terminator] terminatorId=[2eJG] error=[invalid terminator: not found]} terminator not found
[16181.255] ERROR edge/controller/handler_edge_ctrl.(*baseRequestHandler).returnError [ch{wYXvHOJa9x}->u{classic}->i{PJld}]: {token=[5b73f46d-51af-402c-9a6d-59b7947ee7eb] error=[invalid terminator: not found] operation=[remove.terminator] routerId=[wYXvHOJa9x]} responded with error
[39890.291] INFO edge/controller/handler_edge_ctrl.(*createTerminatorHandler).CreateTerminator [ch{wYXvHOJa9x}->u{classic}->i{PJld}]: {token=[4b3089a9-8e23-41c1-975d-7b307ce19312] terminator=[7VaG] serviceId=[B0GNX-e-H] service=[httpz] routerId=[wYXvHOJa9x]} created terminator
[40508.134] INFO : http: TLS handshake error from 111.220.140.199:49738: remote error: tls: unknown certificate
[40508.134] INFO : http: TLS handshake error from 111.220.140.199:49739: remote error: tls: unknown certificate
[40512.952] INFO : http: TLS handshake error from 111.220.140.199:49740: read tcp 10.0.0.41:1280->111.220.140.199:49740: i/o timeout
[40601.567] INFO : http: TLS handshake error from 111.220.140.199:49744: EOF
[40601.606] INFO : http: TLS handshake error from 111.220.140.199:49745: EOF
[40601.647] INFO : http: TLS handshake error from 111.220.140.199:49746: EOF
[40601.691] INFO :

This is a pretty clear indicator that the identity has no edge routers available. Don’t start fresh - we can fix this :slight_smile:

This is a case where you want to run that policy-advisor again:

ziti edge policy-advisor identities -q

If you do that - i expect it’ll tell you the mobile identity doesn’t have any edge routers assigned.

Generally speaking that means the edge-router-policy is wrong/bad somehow…

Try:

ziti edge list edge-router-policies
id: myD3kJ9zHB    name: allEdgeRouters    edge router roles: [#public]    identity roles: [#all]
id: yquHlRvrS5    name: edge-router-yquHlRvrS5-system    edge router roles: [@ip-172-31-42-64-edge-router]    identity roles: [@ip-172-31-42-64-edge-router]
results: 1-2 of 2

Then find your identity and make sure it matches a policy:

ziti edge list identities 'name = "cdaws-mobile"'
id: LqG6R0O6yX    name: cdaws-mobile    type: Device    role attributes: ["http-clients"]

Notice that i have a policy saying: ANY edge router with the attribute of “public” is available for any identity with the #all attribute. (#all is special - it means any/every/all)

Now check the edge router:

ziti edge list edge-routers
id: yquHlRvrS5    name: ip-172-31-42-64-edge-router    isOnline: true    cost: 0    noTraversal: false    role attributes: ["public"]

In my case the “public” edge routers are available for any endpoint… Check your edge router to see if the attribute has been lost or add a policy that is similar to these…

Make sense?

Thanks… I checked those settings… they look to be ok… see details below

Is there anything else I can check?

ziti edge list edge-router-policies

id: rKOwHFJ1W name: allEdgeRouters edge router roles: [#public] identity roles: [#all]

id: wYXvHOJa9x name: edge-router-wYXvHOJa9x-system edge router roles: [@instance-20220317-1005-edge-router] identity roles: [@instance-20220317-1005-edge-router]
results: 1-2 of 2

[opc@instance-20220317-1005 ~]$ ziti edge list edge-routers

id: wYXvHOJa9x name: instance-20220317-1005-edge-router isOnline: true cost: 0 noTraversal: false role attributes: [“public”]
results: 1-1 of 1

Maybe this is where I am going wrong

Should the server identity have the same attribute as the client?

[opc@instance-20220317-1005 ~]$ ziti edge list identities

id: Aa6UKAEog name: Default Admin type: User role attributes: {}

id: Esi5EwO-H name: httpzClient type: Device role attributes: [“http-clients”]

id: HRCgSwecu name: httpzServer type: Device role attributes: [“httpzServerEndpoints”]

I thought to include a list of the service policies also

[opc@instance-20220317-1005 ~]$ ziti edge list service-policies

id: 6Zli6cOcu name: httpz-bind-policy type: Bind service roles:
[@httpz] identity roles: [@httpzServer] posture check roles: []

id: RMkz7cecu4 name: httpz-dial-policy type: Dial service roles:
[@httpz] identity roles: [@httpzClient] posture check roles: []

ahh. ok… maybe I need to add @httpz to the edge router policy…

What’s policy advisor tell you?

ziti edge policy-advisor identities -q

ERROR: instance-20220317-1005-edge-router

  • Identity does not have access to any services. Adjust service policies.

Just for the edge router though right? That doesn’t matter. What identity is the “bind” and what identity is the “client” and what does the FULL policy advisor results show you?

[opc@instance-20220317-1005 ~]$ ziti edge policy-advisor identities -q
ERROR: Default Admin

  • Identity does not have access to any services. Adjust service policies.

OKAY : httpzClient (1) → httpz (1) Common Routers: (1/1) Dial: Y Bind: N

OKAY : httpzServer (1) → httpz (1) Common Routers: (1/1) Dial: N Bind: Y

ERROR: instance-20220317-1005-edge-router

  • Identity does not have access to any services. Adjust service policies

ok cool. you have two identities. the httpzClient should be able to DIAL… the httpzServer should be able to bind…

When you turn the server identity on, the mobile client still won’t connect, correct? Would you be willing to send your mobile’s logs to help at openziti.org?