Hello, Im trying to deploy Ziti. I ve made a few exercises here and there but after a cleanup of my test network i somehow managed to break the web console. Its giving 404 and there are no logs or warnings on the logs :.
I' ve also been searching the forums a lot and found nice implementations ideas. Right now my idea is to start over and better document my process but before doing that I want to ask a few( too many!) questions.
Lab description:
2 Oracle instances, 2 PCs and a raspi at home.
Currently I have one instance with traefik listening on WAN and vpn iface (tailscale), which proxies all my services ( using valid LE certificates) to some remote host.
The other one is running various docker containers and a local flask app. and the last one is running a ziti controller and router published using a hostname.
What Im looking to accomplish:
Access to some services from a subset of my devices. Example: my phone does not need access to database server, but my workstation does.
I wan to access a webapp (uptimekuma.ziti) running in a container from my devices.
Reading at the forums I saw a few posts regarding mapping services to names but had issues to make that work too. Here the policy is missing, right?
I frequently expose apps and ports on my personal machine by creating a simple yaml in traefik. While I could just call to service.ziti from there, similar to what I already do, I guess I can use zrok to expose it to a public internet, right?
Regarding DNS features:
In this mode ziti-tunnel will also serve as an OpenZiti nameserver. So i can have a local dns server, which i need to manually setup.
so, the tunneler automatically serves DNS and configures the machine, then?
Misc:
Can I control zrok assigned hostnames while selfhosting? (I do not understand zrok private publish...)
Can I run everything that needs to be exposed using a single port (443 for example)? I've seen some posts mentioning SNI
In which cases I prefer a tunneler or an edge-router? Can they be exposed to internet?
Reading docs regarding tunnel listeners, is not clear to me if resolver option depends on tproxy or also works in host mode. btw, zedsDemoHttpHttpbin under the services stanza, corresponds to a controller service name?
Hi @el_Lui, welcome to the community and to OpenZiti (and to zrok it sounds like -- or mabye BrowZer too!)
Yes. A tunneler will surface services with an intercept.v1 config within it's built-in nameserver. So if you create a service, add an intercept.v1 config to it with one or more addresses such as: my.service.totally-a-valid-tld, then you will be able to resolve that FQDN. Every OS does this somewhat differently. There's variations here and there with the implementation but the end result is the same. You'll have totally private name resolution only for authenticated identities...
I'm not up-to-speed on all the different things one can do with zrok, but if you self-host a zrok instance you would be able to control the domain name, and with zrok's reserved shares you can also control the 'service' name. So you could have a service such as https://example.clint.demo.openziti.org:8445 (where i reserved example and the zrok api share is at *.clint.demo.openziti.org). I am pretty sure you can also have numerous front-ends and probably could do other cool stuff with the zrok caddy integration.
Define "everything"? Probably not... I would expect one port for the controller (api and control plane), one port for a router (control plane and data plane), one port for zrok and one port for browzer. They would be four separate processes, thus four separate ports would be needed in that setup.
Generally speaking, I think of ziti-edge-tunnel (linux), Ziti Desktop Edge for Mac/Windows as "client" type entities. They are for PC's and "users". Mostly because they are inherintely multi-network-aware (they participate on as many networks as you want) but they also often have UI's too and other "human-things". At this time they also do not serve as 'edge routers -- as things that accept other connection to onboard other devices onto the overlay. That's specifically a router's job. Routers also only have one identity at a time and are geared to move data between endpoints. They are horribly useful at offloading data from the overlay network back to the underlay though so they are used as offload locations a lot. They are also much better suited to be stuffed into a docker runtime than ziti-edge-tunnel is. There's probably other things, but that's a good 'gist'. So for "people" == ziti-edge-tunnel/ZDEW/ZDEM/mobile tunneler... for "servers" == router.
Not quite sure I understand but I think "yes". Running a router in tproxy mode will allow the router to "intercept" traffic and is necessary if you want the router to intercept traffic. Running a router in "host" mode - specifically prevents intercepting traffic (which is the default).
Hi TheLumberjack, thanks for taking the time for helping, I'll try to get a new net running stable before doing crazy setups. I wish to try browZer eventually, but I have more than I can chew for now! XD
Is there anything I need to get in consideration to prepare for that while creating a new net?
Do you have at hand documentation to do it?
After reading your post, I realized two of my questions were mostly similar but I was not clear: is the router able to run a dns server too? Reading at the router config options in the docs, I the 'resolver' keyword under tunnel listener. Is this defining what resolver to use or starting a resolver in that address?
For reference:
listeners:
- binding: tunnel
options:
mode: tproxy
resolver: udp://127.0.0.1:53
dnsSvcIpRange: 100.80.0.0/12 # optionally customize the dynamic IP range used by Ziti DNS
--
Last one, I promise: How do I debug basic network issues? I tried to run a tcpdump but did not have luck capturing packets
I don't think so? I don't exactly know tbh, it depends. I assume you're starting all over fresh and clean so you want to make sure you find and stop any edge routers that are trying to connect and any identities connecting or you'll see periodic failures in logs... Other than that, I can't imagine what else there is to know...
Yes. It does this. You can influence it as you found. Here's a relevant guide for you. It has a video attached too you might find useful to watch.
There's no good way really. It does depend on 'what' you're debugging... If you need to see the payloads, your only option is to capture the traffic before it lands in your tunneler of choice. Once it's on the OpenZiti overlay, you'll have no ability to inspect the payloads anywhere (it's a zero trust overlay network after all).
There are ways around that but it all depends on 'what' you're doing. For example using http would allow you to see the bytes just before getting on the overlay and as they exit the overlay. That's almost always "enough" imo. Other than that you'll be forced to look at TCP packets and the interactions exclusively. @mike.gorman has a bit more experience here if you want to get deeper. I'm sure he'd have extra info for you if you find you need it.
Ok so "general troubleshooting when things go wrong". Yes that's something you'll end up getting used to. The answer is always 'the logs'.
You can use the logs to check:
if the identity received a service
the intercept config to make sure it looks right and is what you expect
if the service was intercepted when the client connects
to see if there are errors giving some indication of a problem
First place is always to look at the logs. Personally I always start on the client side and if things look good, I'll then go over to the "termination" (far/server/offload point/whatever you want to call it) and look at those logs for similar errors.
If the logs are looking ok, then you often need to figure something else out. COMMON problems are misconfigurations that are not easy for humans to detect. extra spaces, spelling errors etc. Other common errors are blocked firewall ports (leading to log errors), offline routers (leading to errors in the logs), bad policies (leading to no services being shown in the logs)... Those are probably the most common issues.
Hi, I successfully published a few services! Thanks again for your help.
I have a case which is not working for me...: I have server with a router and intercepting requests for my database.server' s IP. Intercept works fantastic, however containers in this host can not see the database server.
Do you know if this is expected? Maybe my firewall is messed up.
I've also noticed under host.v1 healtchecks/actions. If you set to send event, what needs to be done to interact with a received event?
PS: If you sed the identity of the dialOptions to a tag/appData, and it's missing, whats the behavior?
It's hard to know exactly the reason without understanding the overall topology. It sounds like you have an ubuntu server and on that server you have deployed a router and other docker containers? I am not certain about this but I believe for this to work you'll have to use the host network for your docker containers. --network host or network_mode: "host".
Can you share how you made the config so I/we can have a look?
I don't actually understand what you mean. Maybe provide me a command you're running so I can understand better?
Hi, Thanks for the container tip. Can' t do that, but in that specific app, I can use the python SDK for sure.
Regarding loglevel of the router, how do I reduce it? It ziti router --verbose 2 run instance-3.ziti.yaml is not working.
For (the missing) context, im refering to a host.v1 http/tcpChecks and actions.
The send_event - doc says: causes an event to be emitted from the controller. Useful for alerting or external integrations. So, how do I connect my external integration here?
