In our environment we have centos7 installed on 90%+ fleet which has older systemd with no support for systemd-resolved split dns capability needed by ziti-edge-tunnel. So as far as I understand I have 2 options -
Deploy edge-router as LAN gateway and use that to tunnel traffic to ziti network from ziti-oblivious clients ( need changes on client to use router as preferred DNS resolver as well as router should be available on the same L2 network domain )
Install ziti-tunnel on clients with config to use /etc/hosts to manage ziti services hostname resolution and ability to modify iptable routes to route traffic.
Does this make sense? Any suggestions / recommendations / alternate options?
OR is it possible to run ziti-edge-tunnel with some additional config where it doesnt have to depend on systemd-resolved?
When tried using ziti-tunnel on client and using /etc/hosts to keep track of ziti service hostnames, we observed that /etc/hosts keep getting appended with ziti service hostnames but the entries are not deleted, is that expected?
I think we used to be able to prepend the name server in dhcpclient conf file with ziti edge tunnel to make it work if I recall it correctly. Try this if available and you have not tried it yet.
Insert “prepend domain-name-servers 100.64.0.2;” into /etc/dhclient.conf or /etc/dhcp/dhclient.conf file on your centos machine. You may have to reboot your vm.
ziti-edge-tunnel should fall back to updating /etc/resolv.conf if it detects that systemd-resolved is not being used. It should try to work with systemd-resolved by checking via dbus API followed by executables (busctl, resolvectl, and systemd-resolve commands). If it can’t work with systemd-resolved then it updates /etc/resolv.conf. It sounds like the resolver detection may not be working as expected.
What do you see when you start ziti-edge-tunnel? What does /etc/resolv.conf look like? Is it a symlink?
Good idea. I always tried with systemd-resolved and when I realized systemd-resolve / resolvectl binary is not in the path by then /etc/resolv.conf was already a symlink.
I can go back and start on centos 7 without doing anything with systems-resolved and see the behavior.
Just to be clear…are you using the ziti-edge-tunnel or ziti-tunnel binary on CentOS 7?
The ziti-edge-tunnel code (not the same code as ziti-tunnel or ziti-router binaries) should already handle the situation gracefully when it cannot find some valid means of configuring systemd-resolved. It shoud fallback to /etc/resolv.conf direct manipulation. (Handling of /etc/resolv.conf manipulation needs some improvement, but should “work” on CentOS 7.)
The go codebase probably needs enhancements in how it handles this situation.
@av-dev You can run with the ziti-edge-tunnel binary with --verbose 6. The detection of systemd resolver is done early on when the binary is launched. It would be useful to see those if ziti-edge-tunnel is not correctly configuring /etc/resolv.conf on CentOS 7.
Additionally, we package ziti-edge-tunnel for CentOS7. You can find details for that here: Installing the RPM
I started with ziti-edge-tunnel but ran into problem without systemd-resolved being available ( which I need to go back and revisit ).
Then while looking for workaround tried edge-router-as-lan-gateway and ziti-tunnel as alternatives.
Will test with fresh centos7 without systemd-resolved and post back my findings.
Feedback is welcomed here. The ziti-edge-tunnel binary received a number of enhancements to the resolver detection logic, so your experience will vary depending on how recent your binary is. I’d encourage you to use the latest release here if possible for the best experience.
