red replies to blue, but the reply packet goes to blue directly through bridge0 without going through iptables. The destination address gets translated to 192.168.15.2:80, and the packet gets sent to red. The answer is simple: According to Hairpin NAT, what happens are: Try running ip netns exec blue curl 192.168.15.1:8080 and we get no response. route_localnet, which allows localhost addresses to pass reroute-check. a SNAT rule to correct the source address of packets sending to the network namespaces so that we can access the published port through addresses other than bridge0, such as 127.0.0.1 or 10.0.2.15. Suppose your machine is connected to the Internet using an interface whose IP address is 10.0.2.15 (this is the default for virtual machines on VirtualBox), now access the published port by curl 192.168.15.1:8080, curl 10.0.2.15:8080 and curl 127.0.0.1:8080 to make sure everything works well. Iptables -t nat -A POSTROUTING -m addrtype -src-type LOCAL -o bridge0 -j MASQUERADE Iptables -t nat -A OUTPUT -p tcp -dport 8080 -j DNAT -to-destination 192.168.15.2:80 To set the parameter, use the following command. _forward is the parameter controlling whether the host could act as a router. The difference between the host and a regular router is that instead of routing traffic for physical machines, the host routes traffic for network namespaces running on itself. In our scenario, the host machine takes traffic from 192.168.15.2 destining 8.8.8.8, but its own IP address is 172.16.94.12, neither the source address nor the destination address. Remember that routers are devices that accept traffic that does not go directly to themselves. Why do we need the kernel parameter _forwarding=1? It turns out that it’s because the host machine should act as a router. a MASQUERADE rule in the host machine setting up source NATĭocker sets up the MASQUERADE rule and the parameter _forward=1 when dockerd starts, and the default routing rule is configured when a container starts. a default routing rule sending traffic to the host machine. This is exactly how Docker containers access the Internet. To access the Internet from red, first we add a default routing rule which sends non-local traffic to the host machine. Access the Internet from a network namespace Docker network host bridge software#
Actually the switch is usually a virtual bridge managed by software instead of a physical switch. In Home network configuration, I said that a typical home router has a switch built-in. It’s crucial to understand the “double roles” of a virtual bridge. When we add an IP address to bridge0 using ip addr add 192.168.15.1/24 dev bridge0, we are actually adding an IP address to the interface. In other words, it’s a bridge from the perspective of the network namespaces, but it’s an interface from the perspective of the host machine. The name bridge0 appears twice: It’s not only the bridge connecting red, blue, and the host machine together, but also the interface that connects to the bridge on the host machine. The setup above is equivalent to the following physical network setup. The word “bridge” is just a synonym for “switch”, but a Linux virtual bridge is more than a switch. You might wonder what a bridge is and why a bridge is added by the ip link command, which is normally used to manage network interfaces. The configuration becomes the following after IP addresses are added. To learn about other namespaces, you can find resources in Containers Deep Dive. However, for this article, we only care about network namespaces. In addition to network namespaces, they use PID namespaces, mount namespaces, UTS namespaces, etc. Notice that Docker (and other container tools) use several namespaces in combination. In other words, network namespaces are like separate machines to the host. Moreover, other networking configurations, like route table (shown by ip route) and iptables are also separated. Run ip link and then ip -n red link, we see that network interfaces are separated. What are separated by network namespaces? This is exactly how Docker enables container-to-host communication for bridge networks.
0 kommentar(er)
