Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Help about MediaWiki
FUTO
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Introduction to a Self Managed Life: a 13 hour & 28 minute presentation by FUTO software
(section)
Main Page
Discussion
English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
= Configuring Our Server’s Networking for Virtual Machines = <span id="what-are-virtual-machines"></span> == What are virtual machines? == We are going to make use of virtual machines a lot. Virtual machines (VMs) are software-based computers running inside your physical server. This approach allows us to have separated, segmented computers running inside of our computer that are '''absolutely idiotproof to back up & restore.''' Key word there being ''idiotproof.'' Once I provide you with a working backup script, if you mess something up with any of the services (mailcow, freepbx, homeassistant syncthing, immich, nextcloud, etc.) all you have to do is: # Shut down the existing messed up virtual machines. # Restore a single <code>.qcow2</code> file from backup. # Start up the virtual machine. And everything works again. No confusing command line stuff, no editing config files. Depending on the host & network you move it to, you might have to edit the IP address configuration & ports forwarded in the firewall; besides that it will just '''work.''' This is beautiful, and so idiotproof even someone like me can do it. If I mess up my phone system, I can restore it in seconds without having to mess with any other part of my system. Did I mention it’s idiotproof? This is the most important quality of a system when I’m the one using it. '''If the server’s hardware or OS drive fails, it’s easy to move the VMs to another device. Insanely easy. Take a backup of a single file & move it over easy.''' <blockquote>'''''nerd note:''' Yes, docker allows for containerized installs of everything. Yes, it’s faster, yes, it makes more sense in an enterprise environment… this is a beginner’s guide. Having a very easy backup script that allows copying & pasting a qcow2 file when you break something means you’ll actually '''''use''''' your backups rather than give up, which is important in the beginning. We will create segmented VMs for each of our purposes (identity/email, android/cloud services & sync, home automation, etc.) and they will have programs & services running in docker within them; often several. The backup solution will be backing up these VMs because it is dirt easy for a beginner vs. managing backing up all associated docker containers & volumes. If you want to manage this, go set up Kubernetes at a mid-sized company for someone & stop reading a newbie guide.'' </blockquote> By running each set of services in its own VM, we isolate them from each other—so if one service has an issue, it won’t bring down the entire system. '''One problem: I need these virtual machines to connect to the internet… and since they’re virtual, they have no network interface card… so I can’t plug them into my switch.''' Since VMs don’t come with physical network interface cards (NICs) like a regular server, we need to create a virtual network interface that allows them to connect to the network and access the internet. This virtual interface acts as a bridge between the VMs and your server’s physical network connection. <span id="step-1-disable-cloud-inits-network-configuration"></span> === Step 1: Disable Cloud-Init’s Network Configuration === Before changing the network configuration, you need to stop cloud-init from managing it. Create the file to disable cloud-init’s network management by running the following command: <code>sudo nano /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg</code> Add this to the file: <code>network: {config: disabled}</code> Save & close the file by typing <code>Ctrl + X</code> and hitting <code>y</code> to save it. <span id="step-2-backup-the-current-netplan-configuration"></span> === Step 2: Backup the Current Netplan Configuration === Make a backup of your current Netplan configuration. Run the following command to back up the current <code>50-cloud-init.yaml</code> file: <code>sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak</code> <code>.bak</code> makes sure that Netplan will not use it for creating a configuration. <code>.bak</code> also makes it easy to go “back” – you don’t have to remember the filename or the location of the original file. You just copy the backup file to the same filename in the same directory without the suffix <code>.bak</code>, there it is. <span id="step-3-create-a-new-netplan-configuration"></span> === Step 3: Create a New Netplan Configuration === Since you disabled cloud-init, you can now modify the network configuration to create a bridge interface that your virtual machines can use. # Find the name of your ethernet interface (the one the CAT5 cable plugs into): <pre>[louis@livingroombauer ~]$ ls /sys/class/net enp4s0 lo</pre> In my personal computer, <code>enp4s0</code> is my network interface, and <code>lo</code> is the '''loopback''' interface. '''loopback''' allows the machine to talk to itself - other computers cannot contact this computer through the loopback interface. This is useful if there is a service we would like to run that we do not want to be accessible to other machines on the network. <code>enp4s0</code> is my ethernet port. On my '''server''', <code>eno1</code> is my interface that the ethernet port plugs into, so I will use that below. When you see me using <code>eno1</code> as I set up my server, replace <code>eno1</code> with the actual name of your network interface. <ol style="list-style-type: decimal;"> <li><p>Create or edit the Netplan configuration file by running this command:</p> <pre>sudo nano /etc/netplan/01-netcfg.yaml</pre></li> <li><p>Replace the content with the following configuration. I’ve added a comment on each line so you know how many spaces there should be:</p> <pre>network: # 0 spaces version: 2 # 4 spaces renderer: networkd # 4 spaces ethernets: # 4 spaces eno1: # 8 spaces dhcp4: no # 12 spaces bridges: # 4 spaces br0: # 8 spaces dhcp4: no # 12 spaces addresses: # 12 spaces - 192.168.5.2/24 # 16 spaces nameservers: # 12 spaces addresses: # 16 spaces - 192.168.5.1 # 20 spaces routes: # 12 spaces - to: default # 16 spaces via: 192.168.5.1 # 18 spaces interfaces: # 12 spaces - eno1 # 16 spaces</pre></li> <li><p>Once done, remember to change the permissions of your netplan file so netplan does not yell at you:</p> <pre>sudo chmod 600 /etc/netplan/01-netcfg.yaml</pre></li></ol> <blockquote>'''Explanation of the Configuration:''' - <code>eno1</code> will be part of the bridge (<code>br0</code>), but will no longer have an IP address directly. - <code>br0</code> is the bridge interface that will be assigned the static IP <code>192.168.5.2</code>. - The <code>br0</code> interface will be configured with the same gateway and nameserver settings as before. The gateway is our pfSense router, which is what it connects to to get an IP address and connect to the internet (a “gateway” to the world), and the nameserver is also our router, which is what it connects to to translate things like google.com into <code>142.250.138.101</code>. - <code>br0</code> is a virtual interface WE are creating. <code>eno1</code> is an interface already present on this machine. <code>eno1</code> is the ethernet port on my computer, simply put. '''Your network interface card will most likely be called something else; this is ok! Use what your network interface is called as it will be different for all machines''' </blockquote> <blockquote>'''NOTE:''' You are probably used to old school configuration files where: <code>pasv_enable=YES</code> is the same as <code>pasv_enable=YES</code> That is not how a YAML do. A single space is all that stands between you having a working setup & happiness, and total misery. YAML is sensitive to spaces; indentation errors matter, and can cause the config file to not work. Some text editors are helpful in editing yaml files so that it is easier to notice mistakes & errors. Some are not. </blockquote> <span id="step-4-apply-the-new-configuration"></span> === Step 4: Apply the New Configuration === Now that the configuration is ready, apply it. <ol style="list-style-type: decimal;"> <li><p>Run the following command to apply the new Netplan configuration:</p> <pre>sudo netplan apply</pre> <blockquote><p>'''NOTE:''' You may make an error because yaml files are evil; to make sure the configuration works, run <code>netplan try</code> before running <code>netplan apply</code>. While yoda had a point with the ''“do or not do there is no try”'', he never dealt with linux documentation.</p></blockquote></li> <li><p>Verify that the bridge interface is up and has the correct configuration by running this command:</p> <pre>ip addr show br0</pre></li> <li><p>You should see that <code>br0</code> has the IP address '''192.168.5.2'''.</p></li> <li><p>Check the routing table to make sure that the default route is correctly set by running:</p> <pre>ip route show</pre></li> <li><p>Verify that the default route points to '''192.168.5.1'''.</p></li></ol> <span id="step-5-test-network-configuration"></span> === Step 5: Test Network Configuration === Verify that your server can still access the network after the changes. <ol style="list-style-type: decimal;"> <li><p>Ping your router by running:</p> <pre>ping 192.168.5.1</pre></li> <li><p>Ping an external IP to make sure connectivity by running. This is Google’s DNS server, which should be up all the time:</p> <pre>ping 8.8.8.8</pre></li></ol> <span id="step-6-add-iptables-rules-for-bridging"></span> === Step 6: Add iptables rules for bridging === For the bridge to work correctly, you need to allow traffic forwarding on the <code>br0</code> bridge interface. This requires creating iptables rules & making them persistent across reboots. This is a very important detail, often [https://www.tecmint.com/create-network-bridge-in-ubuntu/ left out of guides on setting up bridge interfaces]. Skipping this part will result in a setup that doesn’t work; you will be stuck in the hell of posting on GNU/Linux forums where people with IQs of 180+ will tell you to ''“RTFM”'', a man page, that is 2000000+ pages long. This is analogous to Derek Jeter telling you to ''“just keep your eye on the ball.”'' right. You may wonder why that is the case. Setting up things with open source software is like MacBook board repair 12 years ago: it’s a club & you’re not in it. Most teachers know their subject matter. As a result, they forget what it was like to try something for the first time. This is why I am building a machine from scratch as I do this. Telling you how I did it on my machine will never work. There will always be some small detail I subconsciously assume you will know; or perhaps a detail I forgot myself since some of these services I’m showing you were set up in my closet ten years ago! By performing the tasks from what I have written, I am forced to provide you with instructions that '''''actually work!''''' # Run the following commands to add the iptables rules: <pre> sudo iptables -I FORWARD 1 -i br0 -j ACCEPT sudo iptables -I FORWARD 1 -o br0 -j ACCEPT</pre> '''NOTE:''' These iptables rules let traffic go through the bridge interface so your virtual machines can work on your network. Without them, your virtual machines will not be able to connect to anything, and you won’t be able to connect to them. If you see that your virtual machine received an IP address in virtual machine manager, but it can’t connect to anything, you likely skipped this step. > >The order of rules in iptables matters. Inserting rules at the top (using the ‘-I’) puts them at the top. If traffic forwarding does not work as expected, check rules & the order which you can do by running ‘sudo iptables -L -v -n’. <ol start="2" style="list-style-type: decimal;"> <li><p>Verify the iptables rules by running:</p> <pre>sudo iptables -L</pre> <p>You should see the rules for accepting traffic on <code>br0</code>.</p></li></ol> <span id="step-7-make-iptables-rules-persistent"></span> === Step 7: Make iptables Rules Persistent === To make sure the iptables rules are applied after a reboot, you need to save them and configure them to load automatically on startup. <ol style="list-style-type: decimal;"> <li><p>Install the iptables-persistent package:</p> <pre>sudo apt install iptables-persistent</pre></li> <li><p>During installation, you’ll be asked if you want to save the current iptables rules. Choose '''Yes'''.</p></li> <li><p>If you’re not prompted, you can manually save the rules by running:</p> <pre>sudo netfilter-persistent save</pre> <blockquote><p>'''NOTE:''' Installing <code>iptables-persistent</code> is what allows your iptables rules to stick after a reboot. This is a server - you’re not going to turn this off very often. Nine months from now when you DO turn off this server, you’re not going to remember a single damn character from this guide; much less that iptables rule above! Nor will you remember that that rule not being present is why none of your virtual machines work.</p></blockquote></li> <li><p>Confirm the rules are saved by checking the file at <code>/etc/iptables/rules.v4</code>.</p></li></ol> With these changes, your bridge interface will now correctly allow traffic to flow through the virtual machines. The iptables rules will persist across reboots, and your virtual machines will be able to grab IP addresses from the same network as your host machine. <span id="preparing-ubuntu-server-for-virtual-machine-management"></span>
Summary:
Please note that all contributions to FUTO may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
FUTO:Copyrights
for details).
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:
Cancel
Editing help
(opens in new window)