I'm running some docker containers on a server and want to access those containers on their ports after connecting to the server with WireGuard. However when I run the containers in host network mode I can't access them over WireGuard.
They can access each other via localhost. I can even redirect to them with NGINX (but I don't want to actually do this due to security reasons). I can access them on their ports via WireGuard if I run them in bridged mode.
Why can't I access them when running them in host mode? And what can I do to access them? I really want to run the docker containers in host networking mode.
Turns out it was a firewall issue. I had to allow the ip of the WireGuard in the firewall settings on the server.
Related
I have an headless server with VirtualBox. It run multiple virtual machines. One of them is a web proxy. It redirect external access to the right VM in function of the subdomain. Those VMs are communicating between them with internal network (intnet).
I would like to add some docker container to this configuration. How could I successfully create a network shared between my docker containers and this proxy VM ?
I tried to create a bridge network with docker docker network create my_net and then connect the VM with a additional network card in 'bridged' mode.
With this config ping works but not the actual connection. It isn't impossible to display the web page into a browser.
Am I missing some configuration here ? Also, is it a good practice to connect one VM to a docker network ?
Run the containers on one of the VMs. Use a totally normal Docker setup here: create a network for inter-container communication but don't configure it, and completely ignore the container-private network details and IP addresses.
When you use the docker run -p option, that will publish a container's port on its VM's network interface(s). From that point, other VMs can call the published port using that VM's IP address, just as if it were a non-container process running on the VM. Conversely, containers should be able to make outbound calls to the other VMs without special setup.
I'm looking for a way to access containers that are running on server in our company lan by domain names. By far I only managed to access them by IPs
So the setup is. Docker (for windows) is running on server srv1.ourdomain.com (Windows Server 2019), network for container is configured with l2bridge driver, container's dns name, as specifiedn in run command, is cont1. It is accessible by dns name on the docker host (srv1) and by IP from my machine.
What can I do to access the container by dns name cont1.ourdomain.com from my local machine located in the same lan?
I tried to use proxy (traefik) but it cant rewrite urls in the content, so web applications running inside the container are failing. Bacause of this I can't host multiple web application behind that proxy.
I know that it is possible to map container's port to host port and then it will be accessible from lan through the host name and host port, but applications I'm running are requiring many ports to be mapped (like 8 ports for each container) and with those containers being short-lived developer's environments it will be a hell to find a port pool when running new container.
So again if I can access container and its' ports by IP, is there a way to do the same by DNS name?
UPD1. Container host is a virtual server running on vmware. I tried to follow those recommendations and configure promiscuous mode. Thise doesn't help with dns though.
UPD2. I tried transparent network as well. For some reason DHCP can never assign propper IP and container ends up with autoconfigured ip from 168.x.x.x subnet.
You could create a transparent network and make the container discoverable on the network just like host. However, using host ports is what's recommended.
Did you try PathStrip or PathPrefixStrip with Traefik? That should let you rewrite the URLs for the backend.
I have some smart wifi devices on my network I can see from a script on my Mac. But running the same script from within a Docker container those devices are not visible.
I assume this is related to Docker for Mac's inability to connect to the host's network using --network host or network_mode: host. I also assume this issue wouldn't exist on a Linux machine but I don't have one to test on.
What is the workaround?
Edit:
Confirmed this worked fine when running inside an Ubuntu virtualbox, but I'd really not have to develop inside it.
If you start the container with network option as host, the container will share the network stack of the host. Thus any device reachable from you host should be reachable by the container.
docker run --network host ...
Adding containers to a network would allow them to communicate with each other but if you want to access other services running on host then host.docker.internal (from 18.03+). I had to do the same in a mac mini setup to access external service.
[https://docs.docker.com/docker-for-mac/networking/]
If you have to access a service on another host then you can setup an nginx server on the docker host and a proxy pass rule to direct it to the remote service.
I'm new to Docker and Containers, and I'm trying to run a simple asp.net web app in a container but running into issues. My OS is Windows 10 Home, so I have to use the Docker Toolbox, which runs on a VM that only includes a basic Linux OS. When I spin up the container, it seems to start fine, but I can't view the app on the localhost.
$ docker run -p 8342:5000 -it jwarren:project
Hosting environment: Production
Content root path: /app
Now listening on: http://*:5000
Application started. Press Ctrl+C to shut down.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
98cc4aed7586 jwarren:project "dotnet run" 8 minutes ago Up 8 minutes 0.0.0.0:8342->5000/tcp naughty_brattain
I've tried several different recommendations that I found on the web, but none have helped so far. However, my knowledge of networking is very limited, so maybe I'm not fully understanding what needs to be done. I've tried accessing it with the default VM machine IP and the container IP. I understand that the port forwarding does not carry over to the container. Any assistance would be great, as this project is due on Tuesday, and this is the last road block before finishing.
I found the following post that was really helpful: How to connect to a docker container from outside the host (same network) [Windows]. Following the steps below worked perfectly:
Open Oracle VM VirtualBox Manager
Select the VM used by Docker
Click Settings -> Network Adapter 1 should (default?) be "Attached
to:NAT"
Click Advanced -> Port Forwarding Add rule: Protocol TCP, Host Port
8080, Guest Port 8080 (leave Host IP and Guest IP empty)
You should now be able to browse to your container via localhost:8080 and your-internal-ip:8080.
Started up the container (Dockerfile EXPOSES 5000):
docker run -p 8080:5000 -it jwarren:project
Was able to connect with http://localhost:8080
There are few things to consider when working with a VM networking.
Virtual Box has 3 types of networking options NAT, Bridged and Host Only.
NAT would allow your VM to access internet through your internet. But won't allow your HOST machine to access the VM
Host Only network will create a network where the VM can reach the host machine and the Host can reach the VM. No internet using this network
Bridged network will allow your VM to assign another IP from your Wifi router or the main network. This IP will allow VM to have net access as well as access to other machines on the network. This will allow even the host machine to reach the IP
Now in most cases when you want to run Docker inside a VM and access that VM using the host machine you want the VM to have both NAT and Host only bridges
Now accessing your app on port 8342 needs few things checked
seliunx, firewalld, ufw are disabled on your VM (or properly configured to allow the port)
Your VM has a host only network or bridged network
iptables -S should not show REJECT rules
Some VMs come pre-configure to only allow port 22 from external network. So you should try access the app on <hostonlyip>:8342 or <bridgedip>:8342.
If you want to test if the app is up or not you can do the following
docker inspect <containerid> | grep IPA
Get the IP from this and run the command
curl http://<containerip>:5000/
This command needs to be execute inside the VM and not on your machine. If this command doesn't work then your container is not listening on 5000. Sometimes app listen to only 127.0.0.1 inside the container. This means they will work only inside the container and not outside. The app inside the container needs to listen to 0.0.0.0
If nothing works you can try an ssh tunnel approach
ssh -L 8342:127.0.0.1:8342 user#<VMIP>
And then you should be able to access the app on localhost:8342
I'm running virtualbox locally and I've used port forwarding like this
0.0.0.0:7000 -> 0.0.0.0:7000
so that I can do
curl http://localhost:7000
from host to vm and be able to communicate with the application running in the vm and listening to port 7000.
Is it possible to make the reverse? I want to set a port forward to be able to
curl http://localhost:6000
from my vm and be able to communicate with the app that runs on host and listens on port 6000.
I'm using NAT.
I already know about bridged network and about using the network IP of my host. I can't use those. All I'm interested in is the above.
Exclaimer:
The reason of the limitations above is because I'm using dinghy with docker and docker-machine. If I change the network to something else than NAT the setup will break. Moreover I can't use something else than localhost since these are the defaults that the apps have and I need them to communicate as if they were running both on host.
Possible options:
Setup an SSH tunnel with ssh -R, see https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work
Setup Nginx or Apache reverse proxy on the vm to forward traffic to host.
Force the VM to think localhost is your host ip by adding it to the /etc/hosts file (this has the potential risk of breaking other services that may depend on localhost being 127.0.0.1)