Open jimlinntu opened 3 years ago
One of the main reasons this is an issue is that's not expected to run the container with networking mode = host. Why do that? At that point why not just use the distributions native container and use this image to manage the config files?
I'm sure there are other bad assumptions when run with host networking namespace.
That said, the implementation looks reasonably clean.
Thanks for your fast reply!
Undeniably, the original ovpn_run
is very simple and beautiful.
However, the reason I added this commit was because I saw this line (it explicitly allows the usage of the host network):
I think unless ovpn_run
strictly denies the usage of the host network,
I believe there are still people using this repository with host network mode without noticing that his/her iptables
rules are not cleared up after this container down.
(maybe for the benefits that he/she can directly access the resource by the same IPs as he originally does on the host network)
Ahh yes, I see your reasoning, the original feature of endorsing host only behavior was a misstep on my part. My concern with these off nominal cases is that they have a long history of breaking because I don't personally use them and they aren't tested.
This PR highlights that point in that the code as originally written pollutes the iptables chains and there was no test to detect it.
Going forward I see two routes:
nftables
because of unified ipv6 support and higher performance. More iptables/ip6tables things are more tech debt at this point.Can you share with me what host networking gets you over a proper docker network setup? From my experience, host networking often only helps those who don't understand Docker's complicated networking schemes.
Resolved the issue: https://github.com/kylemanna/docker-openvpn/issues/630
docker-compose.yml
I used to test.You will find that after my commit,
iptables
will be restored to its original state.(When the
docker-openvpn
is on)(When the
docker-openvpn
is off)