Internal network resources not available if the container was created before the host was connected to the VPN #5
Assignees
Labels
bug
Something isn't working
Comments
|
I reported this issue (containers/podman#10026) to the Podman upstream project, to understand if this is an intended behavior or if there are better approaches to solve it. |
StayPirate
changed the title
StayPirate
added a commit
that referenced
this issue
Jul 27, 2021
Fix #5. If you run secbox for the first time while you are not yet connected to the company VPN, you won't be able to reach out to the internal network resources even after you connect your host system to the VPN. This commit makes the container works with all the network resources independently from when the container was created at the first instance. /etc/resolv.conf is copied over the container from the host system by podman during the container creation. If your host /etc/resolv.conf changes after the container creation, let's say you connect to your company's VPN, the newly added nameservers (provided by the company via DHCP) won't be reflected within the container /etc/resolv.conf. Bind mounting /etc/resolv.conf would be an option, but unfortunately NetworkManager replace the host /etc/resolv.conf instead of updating its content in place. This of course breaks the bind mount. The solution I adopted here is to use a copy of /etc/resolv.conf maintained by secbox, which takes care of syncing it at every run with the host one, without delete or rename the file. For more info check [0][1][2]. [0] containers/podman#11042 [1] containers/podman#10026 [2] #5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Misbehavior
secboxcontainer was unable to access VPN resources because it was created before the VPN was on.Reason
secboxis using--network hostoption at container creation, this (among other capabilities) allows containerized software to share the same resolver of the host system. This permits to containerized tools likeoscto resolve internal domains (like: build.suse.de).The container maintains its own copy of
/etc/resolv.conf, which is copied from the host at the time of the container creation. If the host was configured to use the SUSE internal resolvers once the container was created, then the container would be able to use them since they will be present in its/etc/resolv.conf. Instead, if the container is created while the host is not connected to the VPN, it will inherit a not properly configured/etc/resolv.conf. If the host connect to the VPN only after the container is created, then the host will be able to resolve internal domains since it will be reconfigured to use the internal DNS servers passed via DHCP (and its resolv.conf change), but the copy maintained by the container won't be updated.Workarounds
secboxcreates a disposable container, hence it can be destroyed and recreated on-demand any time. After the VPN connection is established on the host side, the already existing container can be destroyed viasecbox --destroy -fand the next issuedsecboxcommand will recreate the container, this time with access to the VPN resources.secbox --rootand manually update the/etc/resolv.confThe text was updated successfully, but these errors were encountered: