-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ziti-edge-tunnel run in container no longer configures systemd-resolved #519
Comments
Here's an example invocation using the ❯ ZITI_IDENTITY_BASENAME=webhookz1-client1 docker compose run ziti-tun run --verbose=6 --dns-ip-range=100.80.0.0/12
INFO: setting NF_REG_NAME to ${ZITI_IDENTITY_BASENAME} (webhookz1-client1) DEBUG: waiting 1s for /ziti-edge-tunnel/webhookz1-client1.json (or token) to appear
INFO: found identity file /ziti-edge-tunnel/webhookz1-client1.json
DEBUG: evaluating positionals: run --verbose=6 --dns-ip-range=100.80.0.0/12
INFO: running ziti-edge-tunnel
+ ZITI_EDGE_TUNNEL_PID=8
+ wait 8
+ ziti-edge-tunnel run --identity /ziti-edge-tunnel/webhookz1-client1.json --verbose=6 --dns-ip-range=100.80.0.0/12
(8)[ 0.000] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(ip link set tun1 up) returned 0
(8)[ 0.000] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(ip addr add 100.80.0.0 dev tun1) returned 0
(8)[ 0.000] DEBUG ziti-edge-tunnel:tun.c:295 init_dns_maintainer() setting up NETLINK listener (8)[ 0.000] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(ip route add 100.80.0.0/12 dev tun1) returned 0
(8)[ 0.000] INFO tunnel-sdk:ziti_tunnel.c:60 create_tunneler_ctx() Ziti Tunneler SDK (v0.20.0) (8)[ 0.000] INFO tunnel-cbs:ziti_dns.c:171 seed_dns() DNS configured with range 100.80.0.0 - 100.95.255.255 (1048574 ips)
(8)[ 0.000] DEBUG tunnel-sdk:ziti_tunnel.c:321 ziti_tunneler_intercept() intercepting address[udp:100.80.0.1/32:53] service[ziti:dns-resolver] (8)[ 0.018] DEBUG ziti-edge-tunnel:tun.c:271 on_dns_update_time() queuing DNS update
(8)[ 0.018] INFO tunnel-cbs:ziti_tunnel_ctrl.c:864 load_ziti_async() attempting to load ziti instance from file[/ziti-edge-tunnel/webhookz1-client1.json] (8)[ 0.018] INFO tunnel-cbs:ziti_tunnel_ctrl.c:871 load_ziti_async() loading ziti instance from /ziti-edge-tunnel/webhookz1-client1.json
(8)[ 0.018] INFO ziti_log_set_level set log level: root=6 (8)[ 0.018] ERROR ziti-edge-tunnel:tun.c:251 find_dns_updater() could not find a way to configure system resolver. Ziti DNS functionality will be impaired
(8)[ 0.018] INFO ziti-edge-tunnel:ziti-edge-tunnel.c:1100 load_id_cb() identity[/ziti-edge-tunnel/webhookz1-client1.json] loaded
(8)[ 0.018] WARN ziti-edge-tunnel:instance.c:38 find_tunnel_identity() Identity ztx[/ziti-edge-tunnel/webhookz1-client1.json] is not loaded yet or already re
moved. (8)[ 0.018] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(grep -q '^nameserver 100.80.0.1' /etc/resolv.conf) returned 256 |
Relevant portion of the Compose project: version: "3.9"
x-base-service: &base-service
image: openziti/ziti-edge-tunnel
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- .:/ziti-edge-tunnel
- /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket
environment:
- ZITI_IDENTITY_BASENAME # inherit when run like this: ZITI_IDENTITY_BASENAME=AcmeIdentity docker-compose up ziti-tun
- ZITI_ENROLL_TOKEN # ZITI_IDENTITY_BASENAME=AcmeIdentity ZITI_ENROLL_TOKEN={JWT} docker-compose up ziti-tun
- PFXLOG_NO_JSON=true # suppress JSON logging
network_mode: host # use the Docker host's network, not the Docker bridge
privileged: true
services:
ziti-tun: # tunneler for one Ziti identity
<<: *base-service
command:
- --verbose=4
- --dns-ip-range=100.64.64.0/18 |
sabedevops
added a commit
that referenced
this issue
Oct 17, 2022
sabedevops
added a commit
that referenced
this issue
Oct 17, 2022
resolves #519 Moves systemd-resolved symlink guard to the correct scope
scareything
pushed a commit
that referenced
this issue
Oct 18, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It was previously possible to deliver the tunneler to a device and run it in a privileged container as an intercepting proxy with nameserver, but it appears that recent releases always get this error despite having the same run params and environment:
After failing
systemd-resolved
configuration, the tunneler falls back to attempt manipulating/etc/resolv.conf
which is not desirable when running in a container because the container runtime typically provides that file.I'll take the first steps to confirm that this mode of operation is still possible with older releases so we can narrow possible causes.
The text was updated successfully, but these errors were encountered: