Hello and welcome to this video and this video we get introduced to network names, spaces in Linux
networks, names, faces are used by containers like Docker to implement network isolation.
We'll start with a simple host.
As we know already, containers are separated from the underlying host using names faces.
So what are names, faces?
If your host was your house, then names, faces are the rooms within the house that you assign to each
of your children.
The room helps in providing privacy to each child.
Each child can only see what's within his or her room.
They cannot see what happens outside their room.
As far as they're concerned, they're the only person living in the house.
However, as a parent, you have visibility into all the rooms in the house as well as other areas of
the house.
If you wish, you can establish connectivity between two rooms in the house.
When you create a container, you want to make sure that it is isolated, that it does not see any other
processes on the host or any other containers.
So we create a special room for it on our host using a namespace.
As far as the container is concerned, it only sees the processes run by it and thinks that it is on
its own host.
The underlying host, however, has visibility into all of the processes, including those running inside
the containers.
This can be seen when you list the processes from within the container.
You see a single process with the process of one.
When you list the same processes as a route user from the underlying host, you see all the other processes
along with the process running inside the container, this time with a different process.
I think it's the same process running with different process ideas inside and outside the container.
That's how namespace is work.
When it comes to networking, our host has its own interfaces that connect to the local area network.
Our host has its own routing and our tables with information about rest of the network.
We want to seal all of those details from the container.
When the container is created, we create a network namespace for it, that way it has no visibility
to any network related information on the host within its namespace.
The container can have its own virtual interfaces, routing and other tables.
The container has its own interface.
To create a new network namespace on a Linux host, run the IP and add command, in this case, we create
two network names, faces to list the network names faces, run the IP network and as command.
To list the interfaces on my host, I run the IP link command, I see that my host has the Lookback
interface and the e0 interface.
Now, how do we view the same within the network namespace that we created?
How do we run the same command within the red or blue namespace?
Prefix the command with the command IP net and as exec followed by the namespace name, which is red.
Now the IP link command will be executed inside the red namespace.
Another way to do it is to add the dash end option to the original IP link command.
Both of these are the same.
The second one is similar.
But remember, this only works if you intend to run the IP command inside the namespace.
As you can see, it only lets the Lobach interface.
You cannot see the zero interface on the host.
So with names faces, we have successfully prevented the container from seeing the host's interface.
The same is true with the ARB table.
If you run the ARB command on the host, you see a list of entries, but if you run it inside the container,
you see no entries.
And the same for routing table.
Now, as of now, these network names, faces have no network connectivity, they have no interfaces
of their own, and they cannot see the underlying host network.
Let's first look at establishing connectivity between the name spaces themselves, just like how we
would connect to physical machines together using a cable to an Internet interface on each machine,
you can connect to namespace spaces together using a virtual Ethernet pair or a virtual cable.
It's often referred to as a pipe, but I'd like to call it a virtual cable with two interfaces on either
ends to create the cable or on the IP link.
Add command with a type set to visit and specify the two ends with red and blue.
The next step is to attach each interface to the appropriate namespace.
Use the command IP link set with red and red to do that.
Similarly, attach the blue interface to the blue namespace.
We can then assign IP addresses to each of these names faces.
We will use the usual IP ADR command to assign the IP address, but within each namespace we will assign
the red namespace and IP 192 168 15 dot one within assigned the blue namespace and IP 192 168 15 the
two.
We then bring up the interface using the IP link, set up command for each device within the respective
namespace as the links are up and the namespace can now reach each other tripping from the red namespace
to reach the IP of the blue.
If you look at the ARB table on the red namespace, you see it's identified.
It's blue number at 190 to 168, 15 or two with a Mac address.
Similarly, if you list the arc table on the blue namespace, you see it's identified.
It's the red number.
If you compare this with the arc table of the host, you see that the Hosaka table has no idea about
this new namespace, as we have created and no idea about the interfaces we created in them.
You know that word when you have just two names, faces?
What do you do when you have more of them?
How do you enable all of them to communicate with each other?
Just like in the physical world, you create a virtual network inside your host, create a network,
you need a switch.
So to create a virtual network.
You need a virtual switch.
So you create a virtual switch within our host and connect the namespace us to it.
Well, how do you create a virtual switch between our host?
There are multiple solutions available, such as the unity of solution called as Linux print and the
open we switch, etc..
In this example, we will use the Linux Bridge option to create an internal bridge network.
We add a new interface to the host using the IP link.
Add command with the type set to bridge.
We will name it we net zero.
As far as our host is concerned, it is just another interface, just like the interface, it appears
in the output of the IP link command along with the other interfaces.
It's currently down.
So you need to turn it up, use the IP link, set up command to bring it up.
Now for the namespace.
This interface is like a switch that it can connect to.
So think of it as an interface for the host and a switch for the namespace.
So the next step is to connect the names faces to this new virtual network switch.
Earlier we created the cable or the E pair with the Rethread interface on one end and boot interface
on the other because we wanted to connect the two names faces directly.
Now we will be connecting all name spaces to the bridge network, so we need new cables for that purpose.
This cable doesn't make sense anymore, so we will get rid of it.
Use the IP link, delete command to delete the cable.
When you delete the link with one end, the other end gets deleted automatically.
Since they are the repair that has now created new cables to connect the namespace to the bridge from
the IP link and command and create a pair with.
We either add on one end like before, but this time the other end will be named.
We eat red BRM as it connects to the bridge network.
This naming convention will help us easily identify the interfaces that associate to the red namespace.
Similarly, create a cable to connect the blue namespace to the bridge network.
Now that we have the cables ready, it's time to get them connected to the names faces.
To attach one end of this of the interface to the red namespace run.
The IP link said.
We need Red nitens Red Command to attach the other end to the first network run the IP link said command
on the V Repromed and specify the master for it as the Venette Zero Network.
Followed the same procedure to attach the cable to the blue namespace and the bridge network that is
now said IP addresses for these links and turned them up.
We will use the same IP addresses that we used before, 190 to 160 at 15 dot one and 190 to the 168
or 15 or two and finally turn the devices up.
The containers can now reach each other over the network.
So we follow the same procedure to connect the remaining two names faces to the same network.
We now have all four names, faces connected to our internal network, and they can all communicate
with each other.
They have all IP addresses, 190 to 168 for one, two, three and four.
And remember, we assigned our host the IP 190 to 168, one or two from my host.
What if I tried to reach one of these interfaces in this namespace as well at work?
Now my host is on one network and the name spaces are on another.
But what if I really want to establish connectivity between my host and this namespace?
Remember we said that the bridge switch is actually a network interface for the host.
So we do have an interface on the one hand, to do 168 Wi-Fi network on our host since is just another
interface.
All we need to do is assign an IP address to it so we can reach the namespace through it, run the IP
ADR command to set the IP 192 to 168 or 15, not five to this interface.
We can now bring the red namespace from our local host.
Now remember, this entire network is still private and restricted within the host from within the namespace
as you can't reach the outside world, nor can anyone from the outside world reach the services or applications
hosted inside.
The only door to the outside world is the Internet port and the host.
So how do we configure this bridge to reach the network through the Internet port?
So there is another host attached to our network with the address 190 to 168, one or three.
How can I reach this host from within my name spaces?
What happens if I try to ping this host from my namespace?
The blue namespace sees that I'm trying to reach a network at 190 to 160 dot one, which is different
from my current network of 190 to the 168 or 15.
So it looks at its routing table to see how to find that network.
The routing table has no information about other network, so it comes back saying that the network
is unreachable.
So we need to add an entry into the routing table to provide a gateway or door to the outside world.
So how do we find that gateway?
A door or a gateway, as we discussed before, is a system on the local network that connects to the
other network.
So what is a system that has one interface on the network local to the blue namespace, which is the
one only to 160 WiFi network and is also connected to the outside LAN network?
Here's a logical view.
It's the localhost that have all these names faces on so you can bring the names faces.
Remember, our local host has an interface to attach to the private network so you can ping the name
faces.
So our local host is the gateway that connects the two networks together.
We can now add a rote entry in the blue namespace to say all traffic to the 192 168 one network through
the gateway at 190 to 168 15 dot five.
Now remember, our host has two IP addresses, one on the network at 192, 168, 15 or five and another
on the external network and one only two one six eight one two.
Can you use any in the route now?
Because the blue namespace can only reach the gateway and its local network at 190 to 160 at fifty five.
The default gateway should be reachable from your namespace when you add it to your route.
When you try to ping now you no longer get the network unreachable.
Message what?
You still don't get any response back from the ping.
What might be the problem?
We talked about a similar situation in one of our earlier lectures where from our home network we tried
to reach the external Internet through our router.
Our whole network has our internal private IP addresses that the Destination Network don't know about.
So they cannot reach back for this.
We need not enable on our host acting as the gateway here so that it can send the messages to the LAN
in its own name with its own address.
So how do we add that functionality to our host?
You should do that using IP tables at a new rule in the net IP table, in the post routing chain to
masquerade or replace the from address on all packets coming from the source network.
One entity you don't want 68 or 15 or zero with its own IP address.
That way, anyone receiving these packets outside the network will think that they're coming from the
host and not from within.
The namespace is when we try to be now we see that we are able to reach the outside world.
Finally said the land is connected to the Internet.
We want the name spaces to reach the Internet, so we try to bring a server on the Internet at a later
date or later from the blue namespace, we receive a familiar message that the network is unreachable.
But now we know why that is.
We look at the routing table and see that we have routes to the network 100 to 168 one, but not to
anything else.
Since these names visitors can reach any network our hosts can reach.
We can simply say that to reach any external network, talk to our host so we add a default gateway
specifying our host.
We should now be able to reach the outside world from within this namespace.
Now, what about connectivity from the outside world to inside the name spaces, say, for example,
the blue namespace hosts a Web application on for 80.
As of now, the name spaces are on an internal private network and no one from the outside world knows
about that.
We can only access these from the host itself.
If you try to ping the private IP of the namespace from another host on another network, you will see
that it's not reachable, obviously, because that host doesn't know about this private network in order
to make that communication possible.
You have two options.
The two options that we saw in the previous lecture on that.
The first is to give away the identity of the private network to the second host.
So we basically add an IP wrote entry to the second host, telling the host that the network wanted
it to 168 of 15 can be reached through the host at 190 to at one or two.
But we don't want to do that.
The other option is to add a port forwarding rule using IP tables to say any traffic coming to Port
80 on the localhost is to be forwarded to Port 80 on the IP assigned to the blue namespace.
Well, that's it for this video.
Thank you for watching.