Errors on debian12 starting the tunneler

1

I am having issues getting the tunneler application to start on my debial12 systems. Here are the errors I get. I am not finding anything helpful in the logs. My ZAC is working.

root@macbian:~# sudo systemctl start ziti-edge-tunnel.service
Job for ziti-edge-tunnel.service failed because the control process exited with error code.
See "systemctl status ziti-edge-tunnel.service" and "journalctl -xeu ziti-edge-tunnel.service" for details.
root@macbian:~# systemctl status ziti-edge-tunnel.service
● ziti-edge-tunnel.service - Ziti Edge Tunnel
     Loaded: loaded (/etc/systemd/system/ziti-edge-tunnel.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Tue 2023-07-25 01:26:05 AKDT; 2s >
    Process: 38292 ExecStartPre=/opt/openziti/bin/ziti-edge-tunnel.sh (code=exited, status=1/FAILU>
        CPU: 8ms

and here is the logs

root@macbian:~# journalctl -xeu ziti-edge-tunnel.service
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStartPre= process belonging to unit ziti-edge-tunnel.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Jul 25 01:27:42 macbian systemd[1]: ziti-edge-tunnel.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit ziti-edge-tunnel.service has entered the 'failed' state with result 'exit-code'.
Jul 25 01:27:42 macbian systemd[1]: Failed to start ziti-edge-tunnel.service - Ziti Edge Tunnel.
░░ Subject: A start job for unit ziti-edge-tunnel.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░

sometimes there is a .json file (that is empty) in that folder below. sometimes not. I probably delete the contents and recopy the jwt file. (I would REALLY rather cp it and set permissions that do that super hokey pasting of the contents).

root@macbian:~# ls -lah /opt/openziti/etc/identities/
total 12K
drwxrwx--- 2 root ziti 4.0K Jul 25 01:30 .
drwxr-xr-x 3 root root 4.0K Jul 25 01:04 ..
-rw-r--r-- 1 ziti ziti  901 Jul 25 01:19 ziti-id.jwt
2

The JWT file is a "one-time use token." If a JWT is present, ziti-edge-tunnel attempts to enroll the identity and create a JSON file for use on all subsequent runs. Attempts to re-use the JWT will fail. I'm not sure if this is what's happening for you, but your note about copying the JWT files makes me think you might be trying to use one that has already been used.

3

I’m having no problems running ziti-edge-tunnel on Debian 12.
Can you share the output of cat /etc/systemd/system/ziti-edge-tunnel.service?

4

You can isolate the enrollment itself and view the output like this. I’ve saved a fresh token in /tmp to illustate.

$ sudo -u ziti /opt/openziti/bin/ziti-edge-tunnel version      
v0.21.5-local

$ sudo -u ziti /opt/openziti/bin/ziti-edge-tunnel enroll --jwt /tmp/myclient1.jwt --identity /opt/openziti/etc/identities/myclient.json          
(919554)[        0.000]    INFO ziti-sdk:utils.c:188 ziti_log_set_level() set log level: root=3/INFO
(919554)[        0.000]    INFO ziti-sdk:utils.c:188 ziti_log_set_level() set log level: root=3/INFO
(919554)[        0.000]    INFO ziti-sdk:ziti_enroll.c:90 ziti_enroll() Ziti C SDK version 0.32.8 @d7f329f(HEAD) starting enrollment at (2023-07-25T13:51:13.642)

$ sudo -u ziti jq '.ztAPI' /opt/openziti/etc/identities/myclient.json
"https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443"

Could the problem be the client API URL used for enrolling wasn’t reachable? You can see which URL is embedded in the token with a Python one-liner, or by pasting it in https://jwt.io.

$ python -c '
import sys; 
import jwt; 
import json;
claim = jwt.decode(
    jwt=sys.argv[1], 
    algorithms=["RS256"], 
    options={"verify_signature": False}
);
print(json.dumps(claim, indent=4))
' $(</tmp/myclient1.jwt )

{
    "em": "ott",
    "exp": 1690465801,
    "iss": "https://7ce7e424-6a92-4ff2-9459-ebbba32346fa.production.netfoundry.io:443",
    "jti": "ff5ce1ad-5c6d-40ef-871b-2a588399c614",
    "sub": "YRuiT.ACDZ"
}
5

Thanks for all the replies, that certainly helps explain the process.

  1. I am pretty sure the root of the problem is a missing external DNS (I have a separate thread on that).
  2. I am pretty sure that I was, indeed, attempting to enroll an single jwt token more than once. Does an unsuccessful enrollment invalidate that key? I kind of wouldn’t think so, because it would the the controller that would reject it’s reuse… so this puts be back to the DNS issue.
  3. Seeing the underlying command that is running to enroll the token is immensely helpful!
  4. Does the name of the token matter? Or does any .jwt file get picked up?
6

You bet!

No, the token is valid until it expires or is used for enrollment. Anything else is unexpected by me and probably a bug.

Good! Both ziti edge enroll and ziti-edge-tunnel enroll CLIs can perform enrollment with the controller's client API.

The default behavior is to generate a private key and exchange the one-time token for a long-lived client certificate issued by the controller's edge enrollment signer CA. There's also the option to use an existing private key on disk or in a hardware module.

The Linux installer packages provide a systemd service startup script that looks for any readable file named like *.jwt in the identities directory. If enrollment succeeds then it deletes the token file and a file with the same basename and *.json suffix remains containing the enrolled identity configuration.

1 Like