Connecting a docker container through a transparent proxy in a second container - docker

I have two containers, a client container and a proxy container. My goal is to get all of the client's outgoing network traffic (TCP and UDP) to be sent to the proxy container. The proxy container has a local socket that receives all traffic from the client, does some processing on it, then forwards the traffic to its original destination (using a new socket).
I have been able to implement this with real hardware (using two Raspberry Pis), but I'm trying to get this working on Docker now.
Currently, I'm trying to do this by creating two networks, an internal and an external network. The client is connected to the internal network and the proxy is connected to both the internal and external network. I then set the default route for the client to send all traffic the proxy. On the proxy, I have IP tables routes that should be sending content to a local proxy running on the system (using these instructions: https://www.kernel.org/doc/html/latest/networking/tproxy.html). Unfortunately, no connections are made to the proxy socket.
I'm hoping someone can point me in the right direction for getting this to work. I'm happy to describe more about what I've tried, but I worry that might just confuse the issue.

Related

How can I run docker behind the GRE Tunnel?

So I am having a pterodactyl installation on my node,
I am aware that pterodactyl runs using docker so to protect my Backend IP from being exposed when connecting to the servers I am using a GRE Tunnel from X4B.net
After installing the script I was provided by X4B I got this message
Also Note: This script does not adjust the configuration of your applications. You should ensure your applications are bound to 0.0.0.0 or the appropriate tunnel IP.
At first I was confused and tried connecting to my server but nothing worked, so I was thinking that it was due the docker not being bounded to 0.0.0.0
As for the network layout I was provided with:
10.16.1.200/30 Network,
10.16.1.201 Unified Gateway,
10.16.1.202 Bound via NAT to 103.249.70.63,
10.16.1.203 Broadcast
So If I host a minecraft server what IP address would I use?

How does docker-engine handle outgoing and incoming traffic from/to multiple containers?

I currently have about 5 webserver running behind a reverse proxy. I would like to use an external AD to authentificate my users with the ldap protocol. would docker-engine be able to differentiate between each container by itself ?
My current understanding is that it wouldn't be possible without having a containerized directory service or without exposing different port for each container but I'm having doubts. If I ping an external server from my container I'm able to get a reply in that same container without issue. how was the reply able to reach the proper container ?. I'm having trouble understanding how it would be different for any other protocol but then at the same time a reverse proxy is required for serving the content of multiple webservers. If anyone could make it a bit clearer for me I'd greatly appreciate it.
After digging a bit deeper I have found what I was looking for.
Any traffic originating from a container will get routed automatically by docker on a default network with the use of IP masquerading (similar to NAT) through iptables. The way it works is that the packets from the container will get stripped of the container IP address and replaced by the host ip address. The original ip address will be remembered until the tcp session is over. Then the traffic will go to the destination and any reply will be sent back to the host. the reply packets will get stripped of the host ip and sent to the proper container. This is why you can ping another server from a container and get a reply in that same container.
But obviously it doesn't work for incoming traffic to a webserver because the first step is the client starting a session with the webserver. That's why a reverse proxy is required.
I may be missing a few things and may be mistaken about some others but this is the general idea.
TLDR: outgoing traffic (and any reply ) will get routed automatically by docker, you will have to use a reverse proxy to route incoming traffic to multiple container.

Talk to server on docker container with no exposed ports

I have some docker containers talking together through docker bridge networks. They cannot be accessed from outside (I was said) as they are launched from a script with a default command which does not include 'expose' nor '-p' option. I cannot change that script.
I would like to connect to one of this containers which runs a server and listens for requests on port 8080. I tried connecting that bridge to a newly created docker bridge network, but i did not succede.
Now I am thinking of creating a new container and letting it talk to the server one (through bridge networks). As it is a new contaienr I can use the 'expose' or '-p' options, so it would be able to talk to the host machine.
Is it a good idea? How can I forward every request made to that container to the server one and get responses back to the host machine then?
Thanks
Within the default docker network, all ports are exposed. So you only need a container that exposes a port to the host machine and is in the same network as the other containers you have already created.
This is a relatively normal pattern. You can use a reverse proxy like nginx to achieve something like this.
There are some containers that automate this process:
https://github.com/jwilder/nginx-proxy
If you have no control over the other containers though, you will need to write the proxy config by hand.
If the container to which you are trying to connect is an http server, you may be able to use a ready-made container image that can work as an http forwarder (e.g., nginx - it is relatively easy to configure it as an http forwarder).
If you need plain tcp forwarding, you could make a container running 'socat' (socat can work as a tcp forwarder).
NOTE: in either case, you will be exposing a listener that wasn't meant to be on a public address. Do take measures not to allow unauthorized connections.

2 seperate docker stacks can't communicate over 172.x network

In order to debug and setup a pair of docker stacks (one is a client and other a server along with their own private services they each require) using docker compose, I'm running them locally to make sure they're functioning correctly.
They will eventually be communicating across the internet with a nginx server on the server side to act as a reverse proxy. But for now, i'm specifying the client use the 172.19.0.3:1234 address of the server container.
I'm able to curl/ping both the client container and server container from the host machine, but running an interactive session and trying to curl the server's 172.19.0.3:1234 address just times out.
I feel the 172.x is being used incorrectly here. Is their some obvious issue with what I've described so far? What is the better approach for what I'm trying to do.
Seems that after doing some searching, I am in a similar situation to this question: Communicating between Docker containers in different networks on the same host.
I've decided to use docker network connect to connect the client to the server's network for my purposes.

Ban outgoing traffic from docker container

Can I forbid all outgoing traffic from a docker container except a http proxy server, without sophisticated configuration of iptable?
I don't want this container to access any network at all, exception AAA.BBB.CCC.DDD:80. Is there any convenient way to achieve so?
EDIT:
I found that using --internal can do the trick, and link it to a proxy server container on the same host would allow traffic. Is this method secure though?

Resources