This repository was archived by the owner on Mar 16, 2024. It is now read-only.
This repository was archived by the owner on Mar 16, 2024. It is now read-only.
Hard coding "eth0" causes an issue when using podman #93
Open
Description
Hi,
As mentioned in #87, when the container is run via podman
, the network device is tun0
rather than the hard coded eth0
.
Perhaps adding smarts to entry.sh
to determine the tap. Below is an example that I added to my local copy of entry.sh
- see TAP=...
For context, I am providing some lines surrounding where I believe it should go.
I also globally ^eth0^$TAP^
default_gateway=$(ip -4 route | grep 'default via' | awk '{print $3}')
TAP=$(ip --brief a | grep -v '^lo' | awk '{ print $1}')
case "$KILL_SWITCH" in
Activity
pablos-here commentedon Jan 25, 2023
As pointed out elsewhere, the optimal solution is to accept
--env TAP
environment variable that can overrideeth0
.In place of
eth0
, one can use${TAP:=eth0}
, which will resolves toeth0
ifTAP
is not set.wfg commentedon Jan 26, 2023
I'm not too familiar with the subtle differences between Podman and Docker. I assume this is rootless Podman? I'd like to play with it myself.
pablos-here commentedon Jan 27, 2023
I'm late to the entire container game. :) ... better late than never.
I started learning about
podman
last week. As they say, it's a (near) drop-in replacement fordocker
. I do like that it's rootless.Below is a raw shell script that I'm using during test. You can see the similarities with
docker
. It'll be dead-easy for you.My plan is to eventually get a PR for an .md with
podman
differences. We can talk about how you'd prefer to see that: add to the existing README.md or create a separatepodman
area.Thx!
cdeadlock commentedon Jan 29, 2023
This is very dangerous actually: my result was complete removable of default gateway and lost networking.
I don't know if this was because of debian 11 defaults to using enp2s0 style device handles, or because my hardware happened to have 2 network ports, enp3s0 is the second one. But yes using hardcoded eth0 seems risky for many systems.
It was very confusing because the first error message is about ghcr.io "networking not available" which makes you think it never even pulled the image.
But it did pull image, and since I was using the "subnets" i was still able to ssh into the unit for further troubleshooting.
At first I assumed the logical thing to do was install this and test exactly how it acts with no vpn credentials : and I thought the killswitch would only affect anything using the docker networking. This is not the case, the killswitch is in the HOST operating system so it also affects everything outside docker networking too.
The only reason I even suspected this was the killswitch was because i could still ping the indicated "subnet" but not 1.1.1.1.
I could find no entries in nftables nor iptables.
Eventually i saw that "ip route" showed no default.
I could see from another on the same network what this gateway ip was and the fix is
"ip route add default via 192.168.1.254" on my debian 11 system
I will investigate further if the "eth0" is the only problem going on here for this type of system
pablos-here commentedon Jan 29, 2023
Hi @cdeadlock ,
I couldn't replicate your issue with the latest test bits. If you are using
podman
, then yes, the current bits will not work. You'll have to wait until I submit a PR and @wfg has time to review it.If you are not using
podman
, then I would suggest that you open a new issue with steps to replicate the problem.In my environment, I set up my VM with two NICs:
With the new log output, we can see that the container only has one NIC. Furthermore, you can see that the log says that I have remapped
eth0
totap0
(whatpodman
presents).pablos-here commentedon Jan 30, 2023
Here's the output when it is not remapped. As I'm using
podman
, notice the failure.