Lab "Learning to set up networks in GNU / Linux"

No one likes long introductions, so immediately to the point.
In this improvised laboratory, I would like to highlight the work with networks in GNU / Linux
and consider the following topics:

1. We study vlan. We build a network between vm1, vm2 in one vlan. We ping, catch packages, study headings.
2. We break vm1 vm2 into different vlan. Configure intervlan routing with R1.
3. Iptables Customize the masquerade. Simulate access to external networks.
4. Iptables We configure port forwarding for services on vm1 and v2, which are behind NAT.
5. Iptables Configure security zones. We study tcp sessions.

ZY all people are wrong, I am open to your comments, if I wrote some nonsense, I am ready to correct it!

Given: local network consisting of VM1, VM2. Router R1 (also a virtual machine), web server S1.
You can download a ready virtual machine for this lab from the Yandex disk.
Since I tried to submit this article as a lesson, for the most part I do not write commands with text, but I make a screenshot so that they can be driven in with their own hands. It helps to better understand and quickly remember. I fully understand that this is inconvenient, but I decided to choose this approach.


Setup for VM1 - connect as a bridge to the interface. You can choose any interface and begin to browse everything on it. For completeness, I made a bridge adapter (br0, br1) in system 2 and connected vm1, vm2, r1 (adapter 1) to br0, and s1, r1 (adapter 2) to br2.

For the other 3 settings are similar.
')

I. We study vlan. We build a network between vm1, vm2 in one vlan. We ping, catch packages, study headings.

Run vm1 and vm2 and look at the interfaces in our system with the command

ip addr 

(abbreviated ip a)

Add a new device, which will be called eth0.100 and represent a tagged interface with id = 100.

ip link add -
link eth0 - eth0
name eth0.100 - . , vlan.
type vlan - . 8021q - vlan
id 100 - id vlan


Now assign an ip address to this interface:

 ip addr add 10.10.10.10/24 dev eth0.100 

short entry view:

 ip aa 10.10.10.10/24 dev eth0.100 

We draw attention to the following things: no-carrier and DOWN
This means that we do not have a network cable connected to the interface, and the interface itself is in DOWN.

Connect the cable and get the following picture:

And let's turn on the interface using the command:

 ip link set dev eth0.100 up 

Thus, we have created an interface that will receive tagged packets with vlan id = 100 and, accordingly, hang tag 100 on packets when releasing the packet to the network through this interface. and assigned him an ip address 10.10.10.10/24
do the same thing on VM2, assign the address 10.10.10.20/24

Checking connectivity between VM1 and VM2: ping 10.10.10.10 with VM2

To summarize: we created 2 tagged interfaces on a 100-volume vlan-e on 2 machines in 1 LAN and checked the connectivity between them.

We check that all this is not a lie and a provocation! We start on VM1 the listener and we will knock on it with VM2 and we wake up traffic.
1. on VM1 we will start
nohup nc -lvp 3000 &
tcpdump -n host 10.10.10.20 -i eth0 -e

2. on VM2 we will start
nc 10.10.10.10 3000

We see in the headings of the channel level vlan 100. So the packets on the network really go with the tags and these are not the inventions of the mother goose.

Ii. We break vm1 vm2 into different vlan. Configure intervlan routing with R1.

Now let's move on to item 2 - we split these 2 virtuals into different vlans and configure the router.
On VM1:
add interface eth0.200 with tag 200 and assign it the address 192.168.0.2
on VM2:
add interface eth0.300 with tag 300 and assign address 172.16.0.2 to it
(By myself)


Turn on and configure the router R1. On the router, unlike VM1, VM2, you need to create an interface both in vlan 200 and in vlan 300 — this interface will be the gateway in these networks. Assign them the addresses 192.168.0.1, 172.16.0.1.


We check connectivity. Ping from the router 192.168.0.2 and 172.16.0.2. (Incidentally, there was a small problem here, since I was mistaken in setting up eth0.300 on VM2.



So, we have a connection between VM1, R1 and VM2, R1. Let's try to connect VM1, VM2 through R1.
In order for our Router to be able to forward packets between interfaces, it needs to be allowed to it. You need to uncomment the net.ipv4.ip_forward = 1 directive in the /etc/sysctl.conf file and apply the changes with the sysctl -p command.

 # nano /etc/sysctl.conf # sysctl -p net.ipv4.ip_forward = 1 

And now the most important thing. Need to configure routing. There are 3 common ways to do this:
1. specify the default route. those. we do not know where we have the destination ip, so all the packets that do not belong to the local network are sent to the router.
2. specify the gateway for a specific subnet. This should be done if the network is available for different routers.
3. specify the interface for which the one who will accept the package is located This situation occurred to me, for example, if necessary, in the data center to route the subnet. Those. There was a virtual router to the external address of which the data center statically routed the subnet allocated to me. Then I just pointed out that the ip address of this subnet is on one of the router interfaces sticking up inside. Packages were sent to this interface and received on the other side by the virtual users who were assigned these white addresses. those. in this situation, specifying the gateway was completely optional.
Let's see the list of routes on VM1:

 ip ro 

Our virtual machine knows only about 2 subnets: 10.10.10.0/24 & 192.168.0.0/24. About the host 172.16.0.2 does not say anything! because if you try to ping nothing happens:

add the route to the subnet 172.16.0.0/24:

 ip ro add 172.16.0.0/24 via 192.168.0.1 

via - means through whom. those. we send packets to host 192.168.0.1, it will figure it out.
Looking through the routing table the following decision is made:
1. Who is this package for? host 172.16.0.2
2. To send the package 172.16.0.2? host 192.168.0.1
3. What do we know about host 192.168.0.1? he is directly connected. This subnet is ours. at the data link level, we create the source mac address, the source mac address is 192.168.0.1, the source ip is 192.168.0.2, the destination ip address is 172.16.0.2, and is sent via the eth0.200 interface. As the author of the podcast “networks for the smallest” said, the subsequent fate of the package does not bother us.
Let's try to ping the gateway of the neighboring vlan:

 ping 172.16.0.1 

Works! But what will happen if you ping 172.16.0.2? It will not work, because there is no return route. The packet reaches the VM2 host, but VM2 cannot send it back, because does not know where. Let's try to add a route back to VM2.
Add a default route for VM2. You can do this by specifying the subnet and mask (0.0.0.0/0 - that is, absolutely all addresses fall under it) or using the default keyword

We get the same result. And in the end, now VM1 freely pings VM2. Hooray!

To summarize: We learned how to route between 2 vlan using a linux router.

Iii. Iptables Customize the masquerade. Simulate access to external networks.

Add some public server S1. on it, I put apache2 (apt install apache2) and will simulate a web server on the Internet. Whereas our VM1, VM2 are private machines behind the router. The second interface of the router is looking at the improvised Internet.
Add the 2nd interface for R1 - eth1 and already without a VLAN we will configure it with the ip address 8.8.8.100, and on S1 - 8.8.8.8

It is important to remember that all the commands that we entered in the console only work until the reboot. When I added the 2 interface and turned off the virtual machine, after rebooting I received an unconfigured machine, as a result of which all the commands had to be applied again.

If you repeat after me including the VBOX setting, do not forget to add in br1 both network cards on both S1 and R1. Bridge interface in the system can be created with the command

 ip link add br1 type bridge 

.
But in general, the whole lab can be done on one any interface without creating anything.
I accentuate the separation in order to imitate the bridge = a sort of switch.

After setting S1, R1, we check connectivity - perform ping 8.8.8.8 - it should work with R1. Moreover, if we ping with VM2, then there will be no ping.


In addition, if we ping a server with VM1, then it will generally say that the network is unavailable.


Fix it by writing gateway:


Now all 4 cars perfectly ping each other. But it should not be so. Gray addresses should not go online! And that network, where it looks by the second interface R1, should not know where the addresses 172.16. *. *, 192.168. *. * Are located.
Remove the deafult gw from S1:

 ip ro del default 

To summarize: we learned how to prescribe routes to the networks we need, and also learned how to “hide” gray addresses behind the router, releasing all the traffic out through only one white address.

It's time to talk about NAT. NAT (from the English. Network Address Translation - "Network Address Translation") is a mechanism in TCP / IP networks that allows you to convert the IP addresses of transit packets. Also known as IP Masquerading, Network Masquerading and Native Address Translation. We will consider masquerading. this is SourceNAT (SNAT) && DestinationNAT (DNAT).
What do we really need from NAT? But we need the outgoing packet towards S1 to receive the address of the router as the source ip, and when it comes back to get the destination address again the address of the virtual machine.

Set up a masquerade for the subnet 17.16.0.0/24 - execute the following command on the router:

 iptables -t nat -A POSTROUTING -p tcp -m tcp -s 172.16.0.0/24 ! -d 172.16.0.0/24 -j MASQUERADE 

I will not describe in detail how iptables works, because these are many and many beeches and this article is clearly not for that. Here is a very good article to study.
I will pay only attention to ! -d 172.16.0.0/24 ! -d 172.16.0.0/24 : why it is needed. This is necessary to ensure that hosts from the 172.16.0.0/24 subnet that could potentially be located behind the router (for example, remote vpn clients) would not fall under this rule.
You can see the result with the command iptables-save

So what have we accomplished? We set up a masquerade for VM2. This means that when it will knock on S1, then S1 will see the address is not VM2, but the address of the router! A couple of proofs:

and what does S1 see at this moment?

8.8.8.8 communicates perfectly with 8.8.8.100, no 172.16.0.2 and did not smell!
And what happens at this moment on the router? How does this kitchen work? We will listen to the "gray" interface eth0.300

And this is how it looks at the output to the "external" network:


The kernel, depending on the direction of the packet, processes it and substitutes the correct ip addresses. But if we do the same with VM1, then S1 will see gray addresses. and simply will not respond to this request. Look at it yourself. Let me remind you that the GW on S1 must be removed.

To summarize: We hid our gray networks and released hosts for the router, replacing the source address ip with the address of the router. And in the other direction - we learned to forward a certain port of a particular virtual machine “outside” and were able to connect to the gray address of VM1 virtualka from the “public” network from the S1 server.

Iv. Iptables We configure port forwarding for services on vm1 and v2, which are behind NAT

Let us simulate that S1 is a certain client from the Internet and he wants to connect to VM1 (that client, to which there is neither a route, nor a masquerade). Let it be an attempt to connect via ssh. SSH defaults to port 22, but if we have more than 1 such servers, then how to be? In general, in a good way to get rid of the most simple network scanners, ssh should always be removed from port 22. We use port 30022, for example, to access ssh to VM1.

How it works?
S1 sends a packet (s.ip = S1.ip, d.ip = R1.ip; s.port = N, d.port = 30022) which arrives at R1.
R1 Looks through iptables and applies the DNAT rule, and forms a packet (by our rule): (s.ip = S1.ip, d.ip = VM1.ip; s.port = N, d.port = 22)
Looks through the routing table and sends the vm1 packet through the interface eth0.200.

VM1 in turn receives the packet, receives data, and generates a response: (s.ip = VM1.ip, d.ip = S1.ip; s.port = 22, d.port = N).
R1 accepts the packet and restores the original s.ip to which s1 originally addressed:
(s.ip = R1.ip, d.ip = S1.ip; s.port = 22, d.port = N)

This can be achieved as follows:

try to connect:


To summarize: we have learned how to provide access to services located on virtual machines behind a certain router (otherwise you can say - to virtuals behind NAT'om - which is exactly what is most needed)

V. iptables. Configure security zones. We study tcp sessions.

And the last thing I would like to consider in this lesson is the tcp session and the direction of installation of these sessions. So, for example, we will consider 2 segments: server and client. The client, for example, should be able to "go" to the server segment to the domain controller. But the domain controller to do on the client machine is nothing. There are many examples of such examples and why situations can go from one network segment to another and not the other way around. Why might this be necessary? For example, we have a web server that “looks” on the Internet and was “taken over” by an attacker. From this server, he may well try to knock on the corporate network. However, if you prohibit setting sessions from this segment, this will not happen. Those. we at least make life difficult for an intruder. Let's add a rule that will prevent VM2 from going to VM1, and VM1 to VM2 - you can.

We try to go from VM1 to VM2:

and in the opposite direction:

Why it happens? At the moment of establishing a TCP session, a TCP SYN packet arrives (a SYN ACK is answered to it, and then an ACK and the session is considered to be established). The first rule that we wrote down (c NEW) allows forwarding TCP SYN packets from the 192.168.0.0 network to 172.16.0.0.
When the second participant answers this and any subsequent packet, 2 rules on the established sessions fall under the effect and such packets from the 172.16.0.0 network pass. But if he tries to establish a session (or just ping), then the rule 1.2 will not fall, but will fall under the 3rd, which will drop this package. Voila!

To summarize: We have learned how to manage the directions for setting up tcp sessions to control the direction of traffic between security zones.

Thanks for attention!

I post my draft lectures in the telegram channel: t.me/bykvaadm