Before creating the network architecture, wait until the instructor has started the device that will interconnect all participants in the room. The instructor will then tell you the name of the physical host running this device.
This name is represented by teacher in the following diagram, which you should follow:
        

First, start your three switches with s7nsa_hub_switch.py s:9991 s:9992 s:9993 and keep this terminal open.
Once the switches are started, from another terminal, start your four machines: Note that for your machine D, the symbolic name teacher must be replaced with the name of the physical host indicated by the instructor.

Record the number corresponding to your host system name✍: 7 for laurier7, 12 for citron12, 4 for pomme4, 23 for thym23...
This number is represented by XX in the diagram, as part of the addresses assigned to the eth0 and eth3 interface of machine D and to the eth0 interface of machine C✍.
On the host system, download and install the file tuto_05_setup.sh into the SHARED directory.
Then, on each of your machines A, B, C and D, run the command sh SHARED/tuto_05_setup.sh XX, replacing XX with the number you have just recorded from your host system.
This script assigns the addresses as shown in the diagram.
For each of machines A, B and C, it specifies the default route via the address of the appropriate interface on router D.
On router D, the default route points to the instructor's device.

Use ping -R to verify that:

You have probably noticed that, until now, you have mainly used IP addresses in the form 192.168.???.???.
Such addresses are known as private, meaning that anyone on their own site (or at home) can use them however they wish without having any impact whatsoever on the rest of the Internet.
Although many people habitually use the private address range 192.168.???.???, there are others that are just as freely usable. This is described in RFC 1918.
Naturally, it is possible to subdivide these large address ranges into many smaller subnets; this is what was done in the diagram above with 192.168.10.0/24 and 192.168.20.0/24.

In the network you have just set up, there are for the first time public IP addresses: 100.64.???.???.
Such addresses cannot be chosen freely; they must be reserved/assigned by the Internet service provider✍.
The distinction between private and public IP addresses is not based on any technical constraint but is purely a matter of convention: For the purposes of this tutorial, addresses of the form 100.64.0.XX have been chosen to distinguish the external interfaces of the participants' routers connected to the instructor's device, while subnets of the form 100.64.XX.0/24 represent the ranges of public addresses that each participant can use for their “DMZ” subnet.

As things stand, no explicit action has been taken on the routers to prevent the use of private IP addresses outside each participant's network.
Try to communicate (using ping) between your A machine and the C machine of another participant (coordinate with others to carry out this test together).
Using tcpdump -eni eth0 on the D routers at both sites, observe that the ICMP Echo Request packet sent from A does indeed pass through your D router towards the “outside” but is then lost.
In any case, even if it reached its destination, the ICMP Echo Reply packet that should be generated in response would be addressed to a private address that most likely exists on several sites; there would therefore be no reason to deliver it to one site rather than another...

However, it would be desirable for hosts using private addresses to be able to interact with machines on the Internet nevertheless✍.
To achieve this, it is necessary to instruct the operating system of router D to perform Source Network Address Translation (SNAT).
Now complete the firewall configuration on your D router as follows✍: Be sure to set the XX variable to the number you recorded from your host system.
Regardless of the command's rather complicated syntax✍, it instructs the firewall to translate (modify on the fly) the source IP addresses of IP packets originating from the “Internal servers” subnet when those packets leave through the eth0 interface.
It also specifies that the IP address of interface D/eth0 will replace the source IP address of any packet undergoing this translation✍.
Naturally, the firewall keeps track of the translations it performs for outgoing packets and carries out the corresponding reverse translations (on the destination IP address) when the replies to those packets are received.

Repeat the communication attempt between your A machine and a C machine belonging to another participant.
Carefully observe, on your D router, the IP addresses of the packets captured by tcpdump -eni eth1 and tcpdump -eni eth0; observe the address translations on both the outgoing and return paths.
From the point of view of the outside of your network (the remote C machine), it appears as though your D router initiated the communication, whereas inside your network the A machine appears to be communicating directly with its peer.
You can compare this new situation with that of your B machine, which is not affected by this source address translation✍.

The benefits of Source Network Address Translation (SNAT) are twofold:

The C machine has deliberately been placed in a public address range so that it is accessible from the Internet.
The subnet containing services that are directly accessible from outside is commonly referred to as the “DMZ” (“demilitarised zone”).
This subnet requires particularly careful attention because, unlike hosts using private addresses, which are inaccessible, hosts in the “DMZ” are directly exposed to malicious attempts originating from the Internet.
It is therefore essential to secure these particularly exposed hosts as well as their subnet.

A first step is to decouple the public addresses visible from the Internet from the private addresses actually used by these machines.
Indeed, malicious activity generally begins with network reconnaissance to identify vulnerabilities: making things less obvious makes this process more difficult.
Now begin by modifying the addresses of your “DMZ” so that they belong to the private subnet 192.168.30.0/24.
To do this, run the command sh SHARED/tuto_05_setup.sh XX priv on machines C and D, replacing XX with the number you have recorded from your host system.
Check the address changes with ip addr, the new route on C with ip route, and verify with ping 192.168.30.2 that your A and B machines can communicate correctly with the new address of your C machine.

Your C machine is therefore no longer directly accessible from the “outside”.
To make it accessible again, it is necessary to perform Destination Network Address Translation (DNAT, address forwarding).
To do this, complete the firewall configuration on your D router as follows✍: Be sure to set the XX variable to the number you recorded from your host system.
Regardless of the command's rather complicated syntax✍, it instructs the firewall to translate (modify on the fly) the destination IP addresses to the specified private address whenever IP packets are addressed to the chosen public address.
Naturally, the firewall keeps track of the translations it performs for incoming packets and carries out the corresponding reverse translations (on the source IP address) when replies to those packets are generated.

In coordination with another participant, verify that your C machine is indeed accessible from an “outside” A machine using ping 100.64.XX.2 (replacing XX with the number you have recorded from your host system).
Carefully observe, on your D router, the IP addresses of the packets captured by tcpdump -eni eth0 and tcpdump -eni eth3; observe the address translations on both the incoming and return paths.
From the point of view of the outside of your network, it appears as though your C machine has the chosen public IP address, but that is not actually the case!
Indeed, if from your C machine you try to reach another participant's public IP address using ping, you end up in the same situation as the B machine.
Your “DMZ”, now using private addresses, cannot initiate traffic leaving your site; it merely responds to incoming requests.
This property is extremely valuable from a security perspective because malicious activity often attempts to spread from compromised sites✍.
Under these conditions, even if your “DMZ” machine is compromised, it will not be able to send any traffic to the rest of the world.

Another significant advantage of decoupling the visible public addresses from the private addresses actually used lies in the flexibility it provides when reconfiguring the network.
The “DMZ” could be divided into multiple subnets (for security reasons), or conversely several services that apparently run on different machines could be consolidated onto a single machine (for example, due to hardware availability).
From the outside, these architectural details are invisible, allowing them to be modified at any time, for any reason, without the changes being noticeable.

The previous DNAT translation applied to an entire machine, but for security reasons it is recommended to be more specific.
On your D router, edit the firewall configuration using nano /etc/custom/20_firewall_setup.sh (or vi if you are already familiar with it).
Adjust the previous DNAT rule by adding -p tcp --dport 80 right after the public address (before the \ symbol).
Reload this configuration with /etc/custom/20_firewall_setup.sh.
Start a simple TCP server listening on port 80 on your C machine with ncat -lp 80.
Ask another participant to connect to this server from their A machine using ncat 100.64.XX.2 80 (replacing XX with the number you have recorded from your host system).
Lines typed on the keyboard should be transmitted and displayed on both sides.
Verify that, although TCP communication to port 80 of the public address 100.64.XX.2 is possible, a ping command to that same address does not succeed.
You have just selected very precisely which service you are exposing in the “DMZ”.

The distinction between public and private IP addresses, together with the address translation mechanisms seen previously, already makes it possible to distinguish between authorised and unauthorised communications.
In particular, the C machine in the “DMZ” can be accessed from the outside but cannot initiate communication towards the outside (which is a good thing).
However, it can still communicate with your A and B machines, which would be highly problematic if a service in the “DMZ” were compromised.
To achieve more precise control over authorised and prohibited traffic, the firewall can apply filtering rules.

The prudent approach is to consider that any network packet which does not match a rule explicitly allowing it should be dropped by default.
To do this, complete the firewall configuration on your D router as follows✍: Be sure to set the XX variable to the number you recorded from your host system.
Verify using ping that no traffic is any longer permitted to or through your router.

A first permission consists of specifying that packets originating from hosts on the “Internal servers” subnet may reach or pass through the router freely.
Complete the firewall configuration on your D router as follows✍: Be sure to set the XX variable to the number you recorded from your host system.
Note that, in addition to specifying the address range, it is advisable to specify the incoming interface for such packets; this prevents fraudulent packets originating from the “Workstations” or “DMZ” subnets from being forwarded in an attempt to deceive the firewall.
Verify that your A machine can once again reach your B, C and D machines.

Since you have previously made a service on TCP port 80 of your C machine accessible using DNAT, the filtering rules must also allow access to it.
Complete the firewall configuration on your D router as follows✍: Be sure to set the XX variable to the number you recorded from your host system.
Note that, just as in the DNAT rule, TCP port 80 is specified very precisely, and there is no way of accessing any other service on the C machine.
Verify that your B machine can communicate using ncat 192.168.30.2 80 with your C server running ncat -lp 80.
Ask another participant to connect to this server from their A machine using ncat 100.64.XX.2 80 (replacing XX with the number you have recorded from your host system), and verify that this communication is possible again.