meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
linux:docker:network [2020/02/25 16:36] – niziaklinux:docker:network [2020/03/20 20:13] (current) – niziak
Line 1: Line 1:
 +====== Networking ======
 +
 +[[https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/]]
 +
 +In default docker networking:
 +  * traffic from container to world is NATed.
 +  * incoming traffic for mapped port is handled by ''docker-proxy'' process
 +
 +===== Setup default subnet for containers =====
 +
 +By default docker try to choose not conflicting addressing scheme:
 +<code>172.17.0.0/16", 172.18.0.0/16", "172.19.0.0/16", "172.20.0.0/14", "172.24.0.0/14" "172.28.0.0/14", "192.168.0.0/16"</code>
 +
 +but sometimes it doesn't work.
 +
 +<file json | /etc/docker/daemon.json>
 +{
 +    "default-address-pools":
 +    [
 + {"base":"172.17.0.0/16","size":24}
 +    ]
 +}
 +</file>
 +Will assign 16 bit class for docker daemon, and docker daemon will create 24 bit network per each network.
 +
 +
 +Another example:
 +<file json | /etc/docker/daemon.json>
 +{
 +  "bip": "10.200.0.1/24",
 +  "default-address-pools":[
 +    {"base":"10.201.0.0/16","size":24},
 +    {"base":"10.202.0.0/16","size":24}
 +  ]
 +}
 +</file>
 ====== How to connect container to real network ====== ====== How to connect container to real network ======
  
Line 8: Line 44:
 [[http://stackoverflow.com/questions/26539727/giving-a-docker-container-a-routable-ip-address]] [[http://stackoverflow.com/questions/26539727/giving-a-docker-container-a-routable-ip-address]]
  
-====== Use IP alias ======+===== Use IP alias =====
 Simply add additional IP to one of host network interfaces. Then use port mapping to host IP:port during Docker start. Simply add additional IP to one of host network interfaces. Then use port mapping to host IP:port during Docker start.
 **PROBLEM:** If there is a host service listening on all interfaces, it is not possible to use conflicting port. **PROBLEM:** If there is a host service listening on all interfaces, it is not possible to use conflicting port.
  
-====== Host DNAT ======+===== Host DNAT =====
 NOT TESTED. NOT TESTED.
   * Use IP alias like above.   * Use IP alias like above.
   * Use Docker container in classic ways - expose container services on non conflicting host ports.   * Use Docker container in classic ways - expose container services on non conflicting host ports.
   * Use iptables with DNAT to redirect traffic to given IP:port to container exposed port.   * Use iptables with DNAT to redirect traffic to given IP:port to container exposed port.
 +  * Use iptables with SNAT to set correct originating address
  
 +===== Use real host bridge =====
  
-====== Linux Kernel drivers ======+Set docker internal bridge name to real one on host. 
 +NOTE: Docker will manipulate host bridge (assign configured address!) 
 +[[https://serverfault.com/questions/958367/how-do-i-give-a-docker-container-its-own-routable-ip-on-the-original-network]] 
 + 
 + 
 +===== Connect docker bridge with real host bridge ===== 
 + 
 +Reference: [[https://linux-blog.anracom.com/tag/linux-bridge-linking/]] 
 + 
 +Create virtual adapter pair: 
 +<code bash>ip link add dev veth_docker_lan type veth peer name veth_br-lan</code> 
 + 
 +Add each adapter to one of bridges: 
 +<code bash> 
 +brctl addif docker_lan veth_docker_lan 
 +ip link set veth_docker_lan up  
 + 
 +brctl addif br-lan veth_br-lan 
 +ip link set veth_br-lan up  
 +</code> 
 + 
 +ISSUES: In theory it works, but problem with itpables and routing. Conntrack cannot see packets (different NS ?), so all packets are treated as INVALID on firewall. 
 + 
 +   
 +From [[https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/#macvlan]]: 
 +    Before MACVLAN, if you wanted to connect to physical network from a VM or namespace, you would have needed to create TAP/VETH devices and attach one side to a bridge and attach a physical interface to   the bridge on the host at the same time, as shown below. 
 +    Now, with MACVLAN, you can bind a physical interface that is associated with a MACVLAN directly to namespaces, without the need for a bridge. 
 +  
 +===== MACVLAN & IPVLAN ===== 
 + 
 +==== Linux Kernel drivers ====
  
   * **bridge** - gives connectivity between endpoints, but external access requires NAT   * **bridge** - gives connectivity between endpoints, but external access requires NAT
Line 38: Line 106:
       * Autoconfigured EUI-64 IPv6 addresses are based on MAC address. All VMs or containers sharing the same parent interface will auto-generate the same IPv6 address. Ensure that your VMs or containers use static IPv6 addresses or IPv6 privacy addresses and disable SLAAC.       * Autoconfigured EUI-64 IPv6 addresses are based on MAC address. All VMs or containers sharing the same parent interface will auto-generate the same IPv6 address. Ensure that your VMs or containers use static IPv6 addresses or IPv6 privacy addresses and disable SLAAC.
  
-===== macvlan details =====+**NOTE**: Both modes requires support from HW to use multiple MAC. Without it device needs to be switched into promiscuous mode, which is not easy. Working methods: 
 +    * Virtualbox on host machine - during host machine startup it sets own driver  
 + 
 +==== macvlan details ====
  
 [[https://hicu.be/bridge-vs-macvlan]] [[https://hicu.be/bridge-vs-macvlan]]
Line 48: Line 119:
     * **passtrhru** - assign real physical interface for single VM (and gives full controll to interface)     * **passtrhru** - assign real physical interface for single VM (and gives full controll to interface)
  
 +Issue with bridge:
 +    * macvlan0 added to host bridge works bad. It doesn't receive broadcast packets (so it cannot respond to ARP request). When device inside container is switched into promisc mode, everything starts working well.
  
- +    * https://cnly.github.io/2018/11/09/conflicts-and-limitations-of-bridge-and-macvlan-devices.html 
-===== macvlan example =====+==== macvlan example ====
  
 There can be only one macvlan network with the same subnet and gateway. So better is to create network manually: There can be only one macvlan network with the same subnet and gateway. So better is to create network manually:
Line 81: Line 154:
 <code bash>docker network connect --ip="192.168.0.241" real_lan myservice</code> <code bash>docker network connect --ip="192.168.0.241" real_lan myservice</code>
  
-===== communication with host =====+==== communication with host ====
   Linux Macvlan interface types are not able to ping or communicate with the default namespace IP address.    Linux Macvlan interface types are not able to ping or communicate with the default namespace IP address. 
   For example, if you create a container and try to ping the Docker host's eth0 it will not work.    For example, if you create a container and try to ping the Docker host's eth0 it will not work. 
Line 115: Line 188:
  
  
-===== communication from containers to macvlan container =====+==== communication from containers to macvlan container ====
  
 Problem: containers with default network settings (172.22.0.0) cannot communicate with 192.168.0.242 Problem: containers with default network settings (172.22.0.0) cannot communicate with 192.168.0.242
Line 135: Line 208:
  
  
- +=== openvpn ===
-==== openvpn ====+
  
 After above fixes, there is traffic from docker 192.168.0.242 to host 192.168.0.231 and vice versa. After above fixes, there is traffic from docker 192.168.0.242 to host 192.168.0.231 and vice versa.