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/03/01 15:55] – 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.
Line 19: Line 55:
   * Use iptables with SNAT to set correct originating address   * Use iptables with SNAT to set correct originating address
  
-====== Use real host bridge ======+===== Use real host bridge =====
  
 Set docker internal bridge name to real one on host. Set docker internal bridge name to real one on host.
Line 25: Line 61:
 [[https://serverfault.com/questions/958367/how-do-i-give-a-docker-container-its-own-routable-ip-on-the-original-network]] [[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 ======+ 
 +===== Connect docker bridge with real host bridge =====
  
 Reference: [[https://linux-blog.anracom.com/tag/linux-bridge-linking/]] Reference: [[https://linux-blog.anracom.com/tag/linux-bridge-linking/]]
Line 41: Line 78:
 </code> </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.     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.     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 ====
- +
-====== Linux Kernel drivers ======+
  
   * **bridge** - gives connectivity between endpoints, but external access requires NAT   * **bridge** - gives connectivity between endpoints, but external access requires NAT
Line 68: 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 82: Line 123:
  
     * https://cnly.github.io/2018/11/09/conflicts-and-limitations-of-bridge-and-macvlan-devices.html     * 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 113: 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 147: 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 167: 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.