Im a new user of the OpenZiti project after discovering it while looking for ZTN providors. So far, I was able to get everything installed using this guide including the part regarding setting DNS to the public IP;
and ZAC installed via the documentation;
It seems like I have everything set up but putting in my VPS' address 'https://"Public IP":8443, leaves me with a refusal to connect. I followed all the firewall rules as per the first link. I am able to SSH since I set everything up via that but I cannot ping via cmd or resolve on a browser.
If you're getting a refusal to connect on port 8443, are you able to access 8441? That blog post uses the now-older-style quickstart with the "Host It Anywhere" and as such you should have ports 8440, 8441 and 8442 available.
It's easy to check port 8441 as that's an HTTP-based API. Can you confirm you can access the json at that endpoint?
Let's start there and make sure your firewall is configured properly? Oracle (and other VPS) depending on the VM type you choose sometimes require you to disable the firewall in the OS as well as in the cloud vendor.
Great. Now-a-days, I'd probably recommend you download and unzip the ZAC and host it using the controller. I made a gist that you can check out if interested (or you can just run it directly). It'll get the latest zac for you and unzip it to your current directory.
So for example, for my quickstart-based installs, I would download the zac version I wanted (almost always 'the lastest'). Unzip it, then update the controller's config file. That'd look like this:
cd "/home/ubuntu/.ziti/quickstart/$(hostname -s)"
wget https://gist.githubusercontent.com/dovholuknf/18fa4f042ee2a955f771aee30dac1ed0/raw/4e1191e080f38921f127f067fad7f5965450e36e/fetch-zac.sh
bash fetch-zac.sh
Hmm, Maybe its best I wipe and restart from the first guide, then install ZAC via your script instead of that second link?
regarding ports, Why is it now 8441 instead of 8443 like in the guides? Will i still communicating via HTTPS? right now i get cert errors on 8441 using that first guide via the browser.
I think if your controller is running, the few steps I sent are easiest. If you want to use a deployment, which are the newer way to go about things that's another way you could go. Depends on if you find using a package manager easier to use. If that's the case, you may like that experience better.
The small bash script/gist will just download the latest zac and unzip it for you. So it doesn't "do" much. The hardest part is updating the config file and restarting the controller imo
As for the ports, it's always been 8441 for the controller. The difference is that when this guide/blog was written the ZAC was not capable of being hosted by the controller. That changed in the last two years so now you use the port for the controller (and there's only one needed not two). Yes it's still https, its just a different port. You'll also still get the " Your connection is not private" warning because these are self-signed certs, and 100% expected in this configuration, and entirely safe.
Seems like I screwed up futher. I wiped and attempted the newer method of setup using first this guide to set up the instance on OCI;
I then continued installing and setting up the controller via;
For "ZITI_CTRL_ADVERTISED_ADDRESS" I used the public IP (should I have?)
Default port of 1280
And then installed the Console via the package installer;
The config.yml looks exactly as the sample config.
Cant seem to access via browser or even ping the public IP. I have all the firewall rules setup up as per the first link. Notably, port 1280 ingress is missing from the screenshot but I have it included in the Security Group ruleset.
Sadly this sounds to me like a firewall rule of some kind, either in the OS or in the cloud but you make mention that it's included...
You can use ss on the local machine to make sure it's actively listening, or maybe a curl such as curl -sk https://127.0.0.1:1280. This will confirm the controller is running and there's just some sort of firewall issue...
I seemed to have got everyhting running on the Oracle VPS however, when trying to connect a device to the network via the windows client it tails.Looking at the client logs I see;
WARN ziti-sdk:ziti_ctrl.c:177 ctrl_resp_cb() ctrl[https://openziticontroller:8441] request failed: -3008(unknown node or service)
WARN ziti-sdk:ziti_ctrl.c:336 internal_version_cb() ctrl[https://openziticontroller:8441] CONTROLLER_UNAVAILABLE(unknown node or service)
When creating the controller config via the boostrap script, I cant put the controllers external IP in the ZITI_CTRL_ADVERTISED_ADDRESS field. It only access DNS names, which, according to that original guide I had used, wont work properly with Oracle.
If you have control over your own DNS zone, it'll certainly work! I think the blog was simply saying that Oracle (unlike, AWS for example) doesn't grant you a DNS entry by default. By all means, if you can make a DNS entry, make it! It'll save you a lot of heartache in the long run if the IP ever changes... So, I would recommend you use a DNS entry.
The problem you're running into is the advertise address is incorrect for the controller. Sadly, you probably need to "do it again" (i'm so sorry) because your PKI that was generated, I would expect, is almost certainly incorrect.
If you don't have access to a DNS zone you could use sslip. It is a nice DNS-related service that allows you to map any IP. For example 127.0.0.1.sslip.io resolves to 127.0.0.1. 1.2.3.4.sslip.io would resolve to IP 1.2.3.4.
To be honest, I would probably tell you to use the deployment stuff just because it leverages linux package managers. Really you can use whichever one you find the easier to use. The older-style quickstarts are going to go away at some point though, so sticking with a deployment is probably "for the best" in the long-term.
Got it. Will do that then. I have a few questions regarding configuration.
Do I still have install the router via the CLI or can I just install the controller and console via the documenation and use the web interface to deploy the router on that VPC? It looks like I still have to via CLI and include the JWS token/string.
What ports should I be using now? In the original quickstart we had allocations for 8440-8443, plus 10080.
For the controller should I be using;
ZITI_CTRL_ADVERTISED_PORT: 8440
ZITI_CTRL_ADVERTISED_ADDRESS: a dns name of my choosing (cant put external IP)
For the router;
ZITI_CTRL_ADVERTISED_ADDRESS: external IP
ZITI_CTRL_ADVERTISED_PORT: 8440
ZITI_ROUTER_ADVERTISED_ADDRESS: external IP of VPC
ZITI_ROUTER_PORT: 8442
I took these values from that original "host anywhere" guide. I see there are no options for ZITI_CTRL_EDGE_ADVERTISED_ADDRESS and ZITI_CTRL_EDGE_ADVERTISED_PORT anymore. Whats the difference between a router and edge router? After I have the initial VPC setup I'd like to deploy a network router configuration for my home LAN in order to access LAN resources externally to start.
Thank you
Edit: I made an attempt using the specified values. I can access ZAC via ip:8440 but when I configure the router (on ZAC then use JWS value in CLI) it wont light up both green dots. just hte first API dot. When trying to connect a client, I get not available. Maybe I shouldjust use the default 3022 and 1280 ports in the more current documentation?
Not sure, I'm still orienting myself with all the processes for the project. When creating the router in ZAC on the same VPC it doesnt ask for a token. I guess it automatically negotiates the connection since its on the same host? What are the current standard ports being used for a cloud deployment? And for which variables?
I think my issues is im unable to set ZITI_CTRL_ADVERTISED_ADDRESS as an IP address when configuring the controller via the bootstrapping script. Incredibly frustrating that I cannot get the simplest of configs running with an Oracle VPS
Please describe all the steps. How do you generate the configuration? Are you using the bootstrap.bash (with a clean bootstrap.env)?
What shows (from the router)
# set the env vars `ZITI_CTRL_ADVERTISED_ADDRESS' and `ZITI_CTRL_ADVERTISED_PORT' accordingly
curl -ks https://${ZITI_CTRL_ADVERTISED_ADDRESS}:${ZITI_CTRL_ADVERTISED_PORT}
?
The output should print some OpenZiti configuration in json format.
I appreciate that it can be frustrating, sorry about that. We do our best to make it clear and concise. I thought we had solved the "advertised address could not be used as an IP address" issue. I'll have to ask @qrkourier about that one tomorrow (holiday here today).
There aren't any standard ports per-se. The defaults that ziti has always shipped with are: controller-1280 and router-3022, 10080 but depending on how you deploy and configure it, you could have just two ports. The quickstarts started out trying to demonstrate to people a complex configuration with the expecation/hope that people wanted the extra details. The deployments are trying to simplify that. We know this has gotten a bit complicated and I want to redo these docs to help people. It's on my list, we just need to get to it.
Until then, you can choose any ports you like. When you use a deployment for the controller you should setZITI_CTRL_ADVERTISED_ADDRESS, ZITI_CTRL_ADVERTISED_PORT at a miniumum and you can pick any port you like. Since you had 8441 setup and you know that works, if i were you I would have ended up reusing that port for the controller.
For the router, you'll want to supply the ZITI_CTRL_ADVERTISED_ADDRESS, ZITI_CTRL_ADVERTISED_PORT, ZITI_ENROLL_TOKEN, ZITI_ROUTER_ADVERTISED_ADDRESS, ZITI_ROUTER_PORT.
You would create the ZITI_ENROLL_TOKEN either with the ZAC or with the CLI, it won't matter how you create it.
The "edge" is what 99.9% of people will think of as "OpenZiti". It's the data plane, the overlay network side of things. All OpenZiti clients are "edge" clients. I think we will try to eliminate this confusion in the future... The control plane is what makes up the overlay network "itself". It's how the ziti components talk amongst each other: routers to routers, controller to controllers, routers to controllers. OpenZiti allows these to be different, they do not need to be different... So that's the difference. The deployments eliminated "edge" from the nomenclature to try to simplify things...
I think I caught all your questions? If not let us know, thanks to @frm for helping out too! Appreciate that
Sadly this sounds to me like a firewall rule of some kind, either in the OS or in the cloud but you make mention that it's included...