hello all,
long time lurker, first time poster... (advanced apologies for the terrible grammar)
but anyways, I have been working at a project to setup openziti in an "Air-Gap"-ed environment. its not so much cut off from the internet as much as I have the ability to give temporary access to an internet connection for it's initial setup/config.
the environment this gets connected to is behind a facility wide proxy for all HTTP traffic. generally I setup a few env variables to point the system to said proxy... but have found that a lot of your scripts never account for any system proxy in place. (for example, I needed to add the proxy settings into the wgetrc config, and create a specific .curlrc to get your installers working)
sooo that then leads into my first problem, and stop me if I need to take this up with Netfoundry's GIThub, but the whole "ziti_router_auto_enroll" seems to be timing out on "downloading binaries" in the same way all the other scripts would due to our proxy.
and as for the AirGapped stuff, I was just curious if the SoP for running this offline would be to just download and run everything from containers? or perhaps sync/replicate all the repos to a local "facsimile" and just install everything like it would if pulled from your public repos? as much as I would lean on keeping this in the realm of containers... I believe openziti in this whole PoC project may end up needing to run on some bare-metal instances and other IoT like devices.
Thanks,
Stephen D
Hi @daniels, welcome to the community and to OpenZIti and thanks for engaging with the community! 
That's true. Generally speaking, we hadn't had the requirement for supporting them in the past. Recently, we've had the community ask for support though. @scareything has been actively working on support it in our tunnelers (among all the other things he's been doing) so it's coming! The edge-routers recently received support for proxy back with Release v0.30.2 · openziti/ziti · GitHub (Aug 2023).
Here's is fine, but this isn't an area I work on. It probably would have been best to make a new post here on discourse with this question so that I can point someone else to answer it, but for now I'll just point this out and we'll have to interleave responses on this thread.
I see two options. One is you just download ziti itself and just use ziti. The other is to output a whole container to a single file and move it to an "actually air-gapped™" deployment and load it into docker there. Both options are equally viable imo and it's up to you to decide which you like better.
Hope that helps. Lemme know if you need anything clarified and I'll get somone who knows the "ziti_router_auto_enroll" to comment. (They'll likely want to see a log of what happened if you have it?)
Hi @daniels
The ziti_router_auto_enroll uses the Linux default environmental values for proxy support like wget & curl
Example: export HTTPS_PROXY=http://proxy_server:port
Then run the enrollment script as usual
Keep in mind this is completely separate from the ziti configuration, to use those you'd also need to pass in extra flags into the script:
Proxy options
--proxyType: Proxy type, currently supported is "http" (Default: http)(currently only support http)
--proxyAddress: The Address of the proxy (Default: None)
--proxyPort: The port of the proxy (Default: 3128)
These values will be passed into the router configuration, but not necessary if your installation is all local & reachable without going through a proxy.
FYI, we are going to deprecating the ziti_router_auto_enroll in favor of the new packages being created by the OpenZiti team, you can read more about that here: Router Deployment | OpenZiti
The method for using proxy will be different depending on what packaging system you use, but for example, if apt is involved you'd need to add something like this: Acquire::https::Proxy "http://proxy_server:port/"; to your local apt config.
Hope that helps.
thank you all for the info, I happened to figured out that the proxy chaos with the scripts was mostly tied to ....well..... the env variables not being passed to my priv account.
but I am running into other fun things here... like how the ziti_router_auto_enroll insists on downloading the latest "binary" after checking in with the controller.... this will be a problem because some of the deployments will not have internet access... and if I just want to add more routers to this air gapped environment I will need to enroll the other way? (logging in remotely to the controller and doing that whole "edge router create" dealio?)
plus... Ive gotten this error a few times from teh enroll script... stating that the JWT I downloaded was not in the right format? (this was done by just downloading the JWT from the zac console).
soo seeing how the auto_enroll is being deprecated for the scripting included in the debian pkgs... I have been running into the error of the dreaded "unexpected '('" error... .which in my experience is tied to the bash script missing something at the top of the script? or something?
the bootstrap.bash errors out when being ran....
yet when installing the package if you select the "generate a default config" it steps you thru the process of what you would add into that bootstrap.env file. yet there is no indication of that behavior specified in the documentation.
also... I feel crazy reading thru the documentation at times... because I feel like there was a section in a previous version that showed you how to start the router and check to see if its running...
the documentation here seems incomplete? I have inherited this project from a few other people here and the biggest issue I was warned about was the documentation vs the video instruction..... Router Deployment | OpenZiti
I'm sorry to hear you're having a rough go of it... Just to level-set here, at the end of the day you want to be able to setup an openziti overlay network where there's NO internet, right? That is the end goal. You want to use an http proxy for "reasons" (I don't think that's important to me just yet).
Can we maybe start off by just getting the overlay network up and running in that airgapped environment first? Then, move on from there?
Let me know how that sounds. I'd like to take it one step at a time and I feel like you are getting confused by reading different doc for different topics. (which you seem to have just confirmed in your second post). This is compounded (imo) by the fact that you're doing this in a non-internet-connected world.
Would it be ok taking it one step at a time? I think it'll help me, help you
wellll good sir lol
I have a call scheduled with you later today.
and don't get me wrong, I think this is a wonderful tool and the aim to help developers bake all this in from the get go helps in the long run for everyone. I come from more the network based ZTNA solutions... sooo not being on a cloud infra makes me realize how much we take for granted working with an "interconnected system".
basically I foresee this overlay network being utilized in either off the grid SCADA like systems or more so... highly controlled "one way diode" based networks that really just send in data one way via an ICAP/CDS. Pretty much that data flow remains in a cut-off environment for further work.
long story short, I'd love to provide some documentation on this after a few talks if this would benefit everyone? you providing these chats free of service makes me feel like I need to provide something back as well.