ziti-tunnel leftover loopback IP assignments

[qrkourier]

ziti-tunnel 0.20.2 leaves behind IP assignments to the loopback device e.g. lo for each intercept when it exits after a ^C interrupt signal .

$ ziti-tunnel tproxy --dnsSvcIpRange=100.64.192.0/18
...
^C

$ ip address show lo
...
    inet 100.64.192.1/32 scope host lo
       valid_lft forever preferred_lft forever
...

[qrkourier]

@plorenz @scareything I am able to reproduce this problem in ziti-tunnel 0.20.4. Here's another example of the necessary cleanup commands after encountering this problem.

sudo ip addr del 10.10.10.10/32 dev lo
sudo ip addr del 100.64.128.2/32 dev lo
sudo ip addr del 100.64.128.3/32 dev lo

In this example the DNS intercept range used with ziti-tunnel was 10.64.128.0/18, and 10.10.10.10 represents an IP intercept for a service that was available when ziti-tunnel was running. It's not cleaning up after itself.

[qrkourier]

I'm able to reproduce this issue in 0.20.9.

[qrkourier]

@plorenz I reproduced this issue with v0.22.1 after finding it was necessary to manually clean up the leftover loopback assignments.

 /usr/bin/zsh:99> sudo ip addr del 100.64.64.1/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.2/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.3/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.4/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.5/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.6/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.7/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.8/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.9/32 dev lo
 /usr/bin/zsh:99> sudo ip addr del 100.64.64.10/32 dev lo

[plorenz]

Reopening based on comment from @qrkourier

[qrkourier]

Let me know if this is one of those things that "shouldn't be possible" :wink:

If that's the case, then I would suspect some kind of ungraceful exit for ziti-tunnel and I could spend more time reproducing it with your guidance to look for particular conditions or patterns.

[qrkourier]

I verified the NF-INTERCEPT subchain had been cleaned up, and so just the loopback assignments were still in effect.

[qrkourier]

@plorenz I can still reproduce this is in 0.22.11.

[scareything]

I took a quick look and it seems that the tunneler is not adding a cleanup action to remove the address when the service is removed. If I'm right about that then it should be easily corrected so that addresses are removed when services become unavailable to the tunneler's identity.

AdditionalIy we could also set the valid lifetime on addresses that are added to the loopback device (by adding IFA_CACHEINFO attribute when sending the rtnetlink IfAddrmsg messages. The tunneler would need to run a timer that periodically refreshes the address to prevent the kernel from deleting them. This would guarantee that addresses are removed even when the tunneler crashes or is killed with -9.

[qrkourier]

Suggest we close this as a won't fix / known issue for the deprecated Linux tunneler if I understand correctly the problem will only present when ziti-tunnel tproxy doesn't exit gracefully. I suspect the ungraceful exit was related to running in a container which is probably solvable, but may not be worthwhile. I'm straining to think of a compelling use case that would be hampered by this now that the preferred tunneler is so much more capable.