Difference between revisions of "OPS535-L1"
m (Updating Network Diagram) |
m (Protected "OPS535-L1": OER transfer ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
||
(9 intermediate revisions by 2 users not shown) | |||
Line 20: | Line 20: | ||
Perform the following steps on your host: | Perform the following steps on your host: | ||
<ol><li>Use the skills you learned in previous courses to create a new virtual network called default (we are only keeping the same network name as the old one so we don’t have to change it in every VM).</li> | <ol><li>Use the skills you learned in previous courses to create a new virtual network called default (we are only keeping the same network name as the old one so we don’t have to change it in every VM).</li> | ||
− | <ul><li>The address range to provide is determined based on your Network Number (obtained through blackboard): 192.168.X.0/24.</li> | + | <ul><li>The address range to provide is determined based on your Network Number (NN, obtained through blackboard): 192.168.X.0/24. where X = NN+100</li> |
<li>Do not provide DHCP.</li> | <li>Do not provide DHCP.</li> | ||
<li>Allow it to forward to any physical device, but set the mode to ‘Open’. In virt-manager, the major difference between the three modes is the firewall rules that it will set up for you.</li> | <li>Allow it to forward to any physical device, but set the mode to ‘Open’. In virt-manager, the major difference between the three modes is the firewall rules that it will set up for you.</li> | ||
Line 30: | Line 30: | ||
| style="border: 2px solid black;" | Address for external network | | style="border: 2px solid black;" | Address for external network | ||
|- | |- | ||
− | | style="background-color:#66cccc; border: 2px solid black;" | vm1.<yourdomain>.ops | + | | style="background-color:#66cccc; border: 2px solid black;" | vm1.lab.<yourdomain>.ops |
| style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.53/24 | | style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.53/24 | ||
|- | |- | ||
− | | style="background-color:#66cccc; border: 2px solid black;" | vm2.<yourdomain>.ops | + | | style="background-color:#66cccc; border: 2px solid black;" | vm2.lab.<yourdomain>.ops |
| style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.2/24 | | style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.2/24 | ||
|- | |- | ||
− | | style="background-color:#66cccc; border: 2px solid black;" | vm3.<yourdomain>.ops | + | | style="background-color:#66cccc; border: 2px solid black;" | vm3.lab.<yourdomain>.ops |
| style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.3/24 | | style="background-color:#66cccc; border: 2px solid black;" | 192.168.X.3/24 | ||
|} | |} | ||
Line 43: | Line 43: | ||
Having removed the default network, you have also removed the firewall settings it was providing for you that allowed your machines to communicate with the outside world. Perform the following steps on your host. | Having removed the default network, you have also removed the firewall settings it was providing for you that allowed your machines to communicate with the outside world. Perform the following steps on your host. | ||
<ol><li>Set the virtual interface that is assigned to your new virtual network to be part of the ‘external’ zone. Make sure the change will be permanent.</li> | <ol><li>Set the virtual interface that is assigned to your new virtual network to be part of the ‘external’ zone. Make sure the change will be permanent.</li> | ||
− | + | <li>Ensure Masquerading is set to off for this zone. | |
− | <li>Ensure Masquerading is set to off for this zone. | + | <ul><li>While masquerading would allow our machines to reach the network outside by hiding their internal addresses behind the host machine’s address, it would not help us allow new connections to be made to the servers inside our network. We will have to set that up ourselves.</li></ul></li> |
− | <ul><li>While masquerading would allow our machines to reach the network outside by hiding their internal addresses behind the host machine’s address, it would not help us allow new connections to be made to the servers inside our network. We will have to set that up ourselves.</li></ul> | ||
<li>Remove all services from this zone except for ssh and dns (which you may need to add yourself).</li> | <li>Remove all services from this zone except for ssh and dns (which you may need to add yourself).</li> | ||
− | <li>Now that you have removed the excess clutter from the zone, examine it using firewall-cmd --zone=external --list-all (assuming you have not already done so). | + | <li>Now that you have removed the excess clutter from the zone, examine it using firewall-cmd --zone=external --list-all (assuming you have not already done so). |
− | <ul><li>You may also wish to use the old iptables commands to list individual chains. Pay particular attention to FORWARD and POSTROUTING.</li></ul> | + | <ul><li>You may also wish to use the old iptables commands to list individual chains. Pay particular attention to FORWARD and POSTROUTING.</li></ul></li> |
− | <li>Using the --direct option, add a rule to the FORWARD chain that will allow traffic addressed to machines in your 192.168.X.0/24 network. | + | <li>Using the --direct option, add a rule to the FORWARD chain that will allow traffic addressed to machines in your 192.168.X.0/24 network. |
− | <ul><li>While this (and the next step) should also work with the incoming/outgoing interface options, it does not seem to. Use the destination address only.</li></ul> | + | <ul><li>While this (and the next step) should also work with the incoming/outgoing interface options, it does not seem to. Use the destination address only.</li></ul></li> |
<li>Using the --direct option, add a rule to the FORWARD chain that will allow traffic from machines in your 192.168.X.0/24 network addressed to anywhere else.</li> | <li>Using the --direct option, add a rule to the FORWARD chain that will allow traffic from machines in your 192.168.X.0/24 network addressed to anywhere else.</li> | ||
− | <li>The previous two steps will allow traffic between your virtual machines and the outside world, however most machines will not currently respond to them, as they are using addresses in one of the private address ranges. This is not an issue for the other machines in the lab, as they will be expecting these addresses but anyone outside (e.g. when you try to get updates) will not respond.</li> | + | <li>The previous two steps will allow traffic between your virtual machines and the outside world, however most machines will not currently respond to them, as they are using addresses in one of the private address ranges.<!-- This is not an issue for the other machines in the lab, as they will be expecting these addresses but anyone outside (e.g. when you try to get updates) will not respond.--></li> |
− | <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to masquerade all traffic coming from your virtual network. Use a priority value of 3 (we will need to add a few rules before this one shortly). | + | <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to masquerade all traffic coming from your virtual network. Use a priority value of 3 (we will need to add a few rules before this one shortly). |
− | <ul><li>This will cause traffic coming from your network to use your host’s external facing address. Unfortunately, this puts us right back where we started; any traffic your virtual machines send out will have the actual address hidden. We will need to add some rules before this to allow us to communicate with the other machines in the lab without being masqueraded.</li></ul> | + | <ul><li>This will cause traffic coming from your network to use your host’s external facing address. Unfortunately, this puts us right back where we started; any traffic your virtual machines send out will have the actual address hidden. We will need to add some rules before this to allow us to communicate with the other machines in the lab without being masqueraded.</li></ul></li> |
− | <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to ACCEPT all traffic coming from your virtual network that has a destination in 172.16.0.0/16. Use a priority value of 2 so that this rule will happen before the one you just added.</li> | + | <!-- IN-CLASS ONLYE <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to ACCEPT all traffic coming from your virtual network that has a destination in 172.16.0.0/16. Use a priority value of 2 so that this rule will happen before the one you just added.</li> --> |
− | <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to ACCEPT all traffic coming from your virtual network that has a destination in 192.168.0.0/16. Use a priority value of 2 so that this rule will happen before the masquerading one.< | + | <li>Using the --direct option, add a rule to the POSTROUTING chain of the nat table to ACCEPT all traffic coming from your virtual network that has a destination in 192.168.0.0/16. Use a priority value of 2 so that this rule will happen before the masquerading one. |
− | <ul><li>This rule will allow you to communicate with machines in other students’ own networks. We have lumped all of them into one /16 rule instead of having to add a separate rule for each student you wish to communicate with.</li></ul> | + | <!-- IN-CLASS ONLY<ul><li>This rule will allow you to communicate with machines in other students’ own networks. We have lumped all of them into one /16 rule instead of having to add a separate rule for each student you wish to communicate with.</li></ul></li> --> |
− | <li>Use firewall-cmd and iptables -L to examine your firewall again. You should see the rules you added in the FORWARD chain of the filter table, and in the POSTROUTING_direct chain of the nat table.< | + | <ul><li>This rule will allow you to communicate with machines in your assignment network (which you will create later). We have lumped all of them into one /16 rule instead of having to add a separate rule for each network you wish to communicate with. We will adjust this for the assignment</li></ul></li> |
− | <ul><li>Make sure the two rules you added to POSTROUTING that ACCEPT traffic addressed to 172.16.0.0/16 and 192.168.0.0/16 appear before the masquerade rule you added.</li> | + | <li>Use firewall-cmd and iptables -L to examine your firewall again. You should see the rules you added in the FORWARD chain of the filter table, and in the POSTROUTING_direct chain of the nat table. |
− | <li>Once you are satisfied with your firewall, use firewall-cmd --runtime-to-permanent to save it.</li></ul> | + | <!--<ul><li>Make sure the two rules you added to POSTROUTING that ACCEPT traffic addressed to 172.16.0.0/16 and 192.168.0.0/16 appear before the masquerade rule you added.</li> |
+ | <li>Once you are satisfied with your firewall, use firewall-cmd --runtime-to-permanent to save it.</li></ul>--> | ||
+ | <ul><li>Make sure the rule you added to POSTROUTING that ACCEPTs traffic addressed to 192.168.0.0/16 appears before the masquerade rule you added.</li> | ||
+ | <li>Once you are satisfied with your firewall, use firewall-cmd --runtime-to-permanent to save it.</li></ul></li> | ||
<li>Now that your VMs can be reached by the outside world, it is important to differentiate the traffic that is on their internal network from traffic with the outside world. Boot each of your VMs and set the interface that is connected to your internal network to be in the zone called internal, while the interface connected to the open network you just created should be set in the zone called external.</li> | <li>Now that your VMs can be reached by the outside world, it is important to differentiate the traffic that is on their internal network from traffic with the outside world. Boot each of your VMs and set the interface that is connected to your internal network to be in the zone called internal, while the interface connected to the open network you just created should be set in the zone called external.</li> | ||
<ul><li>Make the same changes to the external zone you did on the host (i.e. no masquerading, and delete the unneeded services).</li> | <ul><li>Make the same changes to the external zone you did on the host (i.e. no masquerading, and delete the unneeded services).</li> | ||
<li>Make sure these changes persist past rebooting.</li></ul> | <li>Make sure these changes persist past rebooting.</li></ul> | ||
</ol> | </ol> | ||
+ | |||
+ | <!-- In-class only | ||
==Investigation 3: Routing== | ==Investigation 3: Routing== | ||
In the previous investigation you configured the firewall on the host to allow your virtual machines to communicate with other students’ networks as well as the outside world, but they can not actually reach | In the previous investigation you configured the firewall on the host to allow your virtual machines to communicate with other students’ networks as well as the outside world, but they can not actually reach | ||
Line 76: | Line 80: | ||
<li>On each virtual machine make sure that the interface that is set in the 'external' zone is the only one that has a default route set, and that it is directed to your host machine's address in the same network.</li> | <li>On each virtual machine make sure that the interface that is set in the 'external' zone is the only one that has a default route set, and that it is directed to your host machine's address in the same network.</li> | ||
<li>From your host and all VMs, ping another student’s host and VMs. You should get responses back. If not, go back and trouble shoot your routing rules.</li> | <li>From your host and all VMs, ping another student’s host and VMs. You should get responses back. If not, go back and trouble shoot your routing rules.</li> | ||
+ | <li>Make sure that this behaviour continues past reboot.</li> | ||
</ol> | </ol> | ||
+ | --> | ||
+ | |||
==Completing the Lab== | ==Completing the Lab== | ||
You should now have a better network configuration for your VMs. Each machine has access to the internal-only network it already had, but now has the second network interface configured to allow | You should now have a better network configuration for your VMs. Each machine has access to the internal-only network it already had, but now has the second network interface configured to allow |
Latest revision as of 15:50, 21 July 2023
Contents
OPS535 Lab 1
Resources
- Link to Network Diagram for Labs/Assignments
- Link to virtual-lan setup
- Link for assigned network address lookup
- System Admin Automation using Fabric
Purpose
Libvirtd provides firewall rules to allow access to virtual machines, but assumes all connections will originate from them. It does not have a good setup to allow clients from outside your network to connect to servers you might be hosting on VMs. In this lab you will gain experience managing the firewall rules that allow greater control over traffic, along with routing information to control where outgoing traffic is sent.
Pre-Requisites
The pre-lab must be complete so that your virtual machines share access to a private network. Shut down your VMs and delete the default virtual network from your host.
Investigation 1: Virtual Networks
Perform the following steps on your host:
- Use the skills you learned in previous courses to create a new virtual network called default (we are only keeping the same network name as the old one so we don’t have to change it in every VM).
- The address range to provide is determined based on your Network Number (NN, obtained through blackboard): 192.168.X.0/24. where X = NN+100
- Do not provide DHCP.
- Allow it to forward to any physical device, but set the mode to ‘Open’. In virt-manager, the major difference between the three modes is the firewall rules that it will set up for you.
- Boot each virtual machine and provide it a static address according to the following table. Do not alter the address it already has for your internal network.
Hostname | Address for external network |
vm1.lab.<yourdomain>.ops | 192.168.X.53/24 |
vm2.lab.<yourdomain>.ops | 192.168.X.2/24 |
vm3.lab.<yourdomain>.ops | 192.168.X.3/24 |
Investigation 2: Advanced uses of FirewallD
Having removed the default network, you have also removed the firewall settings it was providing for you that allowed your machines to communicate with the outside world. Perform the following steps on your host.
- Set the virtual interface that is assigned to your new virtual network to be part of the ‘external’ zone. Make sure the change will be permanent.
- Ensure Masquerading is set to off for this zone.
- While masquerading would allow our machines to reach the network outside by hiding their internal addresses behind the host machine’s address, it would not help us allow new connections to be made to the servers inside our network. We will have to set that up ourselves.
- Remove all services from this zone except for ssh and dns (which you may need to add yourself).
- Now that you have removed the excess clutter from the zone, examine it using firewall-cmd --zone=external --list-all (assuming you have not already done so).
- You may also wish to use the old iptables commands to list individual chains. Pay particular attention to FORWARD and POSTROUTING.
- Using the --direct option, add a rule to the FORWARD chain that will allow traffic addressed to machines in your 192.168.X.0/24 network.
- While this (and the next step) should also work with the incoming/outgoing interface options, it does not seem to. Use the destination address only.
- Using the --direct option, add a rule to the FORWARD chain that will allow traffic from machines in your 192.168.X.0/24 network addressed to anywhere else.
- The previous two steps will allow traffic between your virtual machines and the outside world, however most machines will not currently respond to them, as they are using addresses in one of the private address ranges.
- Using the --direct option, add a rule to the POSTROUTING chain of the nat table to masquerade all traffic coming from your virtual network. Use a priority value of 3 (we will need to add a few rules before this one shortly).
- This will cause traffic coming from your network to use your host’s external facing address. Unfortunately, this puts us right back where we started; any traffic your virtual machines send out will have the actual address hidden. We will need to add some rules before this to allow us to communicate with the other machines in the lab without being masqueraded.
- Using the --direct option, add a rule to the POSTROUTING chain of the nat table to ACCEPT all traffic coming from your virtual network that has a destination in 192.168.0.0/16. Use a priority value of 2 so that this rule will happen before the masquerading one.
- This rule will allow you to communicate with machines in your assignment network (which you will create later). We have lumped all of them into one /16 rule instead of having to add a separate rule for each network you wish to communicate with. We will adjust this for the assignment
- Use firewall-cmd and iptables -L to examine your firewall again. You should see the rules you added in the FORWARD chain of the filter table, and in the POSTROUTING_direct chain of the nat table.
- Make sure the rule you added to POSTROUTING that ACCEPTs traffic addressed to 192.168.0.0/16 appears before the masquerade rule you added.
- Once you are satisfied with your firewall, use firewall-cmd --runtime-to-permanent to save it.
- Now that your VMs can be reached by the outside world, it is important to differentiate the traffic that is on their internal network from traffic with the outside world. Boot each of your VMs and set the interface that is connected to your internal network to be in the zone called internal, while the interface connected to the open network you just created should be set in the zone called external.
- Make the same changes to the external zone you did on the host (i.e. no masquerading, and delete the unneeded services).
- Make sure these changes persist past rebooting.
Completing the Lab
You should now have a better network configuration for your VMs. Each machine has access to the internal-only network it already had, but now has the second network interface configured to allow access to other nearby networks (e.g. other networks in the same organization) without undergoing Network Address Translation.
Follow the instructions on blackboard to submit the lab.
Exploration Questions
- What does the priority number in a direct rule for firewalld affect?
- How are direct rules different from rich-rules?