# Linux Networking Home Lab

## Complete Multi-Platform Network & Home Lab Infrastructure

Author: Belal Ezat

Environment: RHEL 9.5 (Bare-metal Server), Fedora Linux (VM Client), Windows (Laptop Client)

Core Services: Docker, WireGuard (BelalVPN), Wazuh, Splunk, SNMP, Nextcloud

***

### 1. Overview

This documentation details the architecture, deployment, and configuration of a resilient, multi-platform home networking lab. The infrastructure centers around a robust Red Hat Enterprise Linux (RHEL) server acting as the primary node, integrating seamless communication with Windows bare-metal clients and Fedora Linux virtual machines.

By leveraging virtualization, Docker containerization, and advanced network management tools, this setup establishes a secure, highly available ecosystem capable of handling enterprise-grade logging, telemetry, and self-hosted cloud storage.

### 2. Infrastructure Prerequisites

Before deploying the core services, the underlying operating environments must be established:

* Primary Server (RHEL 9.5): Chosen for its enterprise-grade stability and lineage from CentOS Stream. The server was initialized with a clean wipe, utilizing Balena Etcher to flash the bootable media. Dedicated root and standard user accounts were created to establish a secure baseline.
* Linux Client (Fedora VM): A virtualized environment integrated into the network to offload specific workloads and act as a secondary client interface.
* Windows Client: A bare-metal machine functioning as a workstation, log aggregator, and network participant. Automated shortcuts have been configured on this machine to bypass repetitive command-line operations.

### 3. Secure Remote Access & VPN Routing

A multi-layered approach ensures encrypted, authenticated communication across all hardware nodes, regardless of geographical location.

#### SSH Key Authentication

Password-based logins are deprecated in favor of cryptographic SSH keys.

* Keys are generated and distributed across the RHEL server and Fedora VM to allow seamless, passwordless automated interactions.
* Hostname resolution is streamlined via `/etc/hosts` configurations (e.g., statically mapping `net-desktop` to `127.0.1.1`).

<figure><img src="/files/1nGAKE2RN9ELOLWqmLKy" alt=""><figcaption></figcaption></figure>

#### Virtual Private Networking (WireGuard)

While Tailscale was initially deployed for a zero-configuration "tailnet," the infrastructure is transitioning to a fully self-hosted, open-source WireGuard deployment named BelalVPN for maximum control.

Server Configuration (`/etc/wireguard/BelalVPN.conf`):

Ini, TOML

```
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <RHEL_SERVER_PRIVATE_KEY>
SaveConfig = true

# Enable Port Forwarding and Masquerading
PostUp = firewall-cmd --zone=public --add-port 51820/udp && firewall-cmd --zone=public --add-masquerade
PostUp = echo 1 > /proc/sys/net/ipv4/ip_forward
PostDown = firewall-cmd --zone=public --remove-port 51820/udp && firewall-cmd --zone=public --remove-masquerade
```

Fedora VM Client Configuration:

Ini, TOML

```
[Peer]
PublicKey = <FEDORA_PUBLIC_KEY>
AllowedIPs = 10.0.0.2/32
```

*(Note: Edge router port forwarding for UDP 51820 is required to allow external handshakes).*

#### Troubleshooting: External Connectivity

Initial out-of-network ping tests for BelalVPN failed, indicating that the edge router was dropping the external WireGuard handshake.

* **Resolution Step:** Access the Asus RT-AX88U edge router portal (`192.168.50.1`), navigate to **WAN** > **Virtual Server / Port Forwarding**, and explicitly forward UDP port `51820` to the RHEL server's local IP address.

### 4. Security Information and Event Management (Wazuh)

To maintain strict oversight of network security, Wazuh is deployed to aggregate and analyze threat intelligence.

* Containerized Deployment: To bypass native package discontinuities on the Fedora VM, the Wazuh manager is deployed within a Docker stack. This isolates the application layer and allows for rapid teardown if dependencies break.
* Internal Security: Internal SSL certificates are generated for the Docker stack, ensuring that Wazuh’s core components authenticate each other securely.
* **Agent Integration & Versioning:** Wazuh agents are deployed on both the RHEL server and the Windows client. During deployment, the latest agent version threw a compatibility error ("too new") when attempting to connect to the manager. To ensure stability, the agents were strictly downgraded to `v4.7.3` to perfectly match the Dockerized manager's version. The RHEL `firewalld` daemon is configured to allow agent-to-manager traffic through ports `1514` and `1515`.

<figure><img src="/files/IyZMvZ4jmiWweYRxwxcD" alt=""><figcaption></figcaption></figure>

### 5. Log Aggregation & Analysis (Splunk)

For deep data visualization and historical event tracking, Splunk Enterprise runs concurrently with the Wazuh implementation.

* Deployment: Hosted locally on the Windows client.
* **Data Ingestion & Integration Pivot:** Initial plans to use the official Wazuh-Splunk application (`https://github.com/wazuh/wazuh-splunk`) were halted due to version incompatibilities between the two platforms. As a fallback, the RHEL server is currently configured to forward raw system events directly via standard `syslog` to the Splunk instance.
* Alerting Framework: Custom Splunk dashboards are built to visualize inbound data. Automated email alerts are configured to trigger upon specific security anomalies, such as repeated failed SSH login attempts.

<figure><img src="/files/UzLDV7DkmzUiA39wtQGA" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/6PG753wVKbxvjiufE15R" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/VIdOI4G6qkkgkLivhY5i" alt=""><figcaption></figcaption></figure>

### 6. Self-Hosted Cloud Storage (Nextcloud)

To decouple from proprietary cloud providers and maintain absolute data sovereignty, Nextcloud is hosted on the RHEL server.

* Docker Network Isolation: Nextcloud and its associated databases are deployed via Docker. An internal Docker network is created so backend containers can communicate efficiently without being exposed to the public internet.
* Persistent Volumes: Docker volumes are explicitly mapped to the host filesystem. This ensures that user files and database states persist safely on the RHEL server, even if the containers are destroyed or updated.
* Access: The platform interface is exposed locally over port `8080`.

### 7. Power Management & Hardware Lifecycle

Running an enterprise server 24/7 generates unnecessary heat and power consumption.

* Wake-on-LAN (WoL): WoL is enabled on the RHEL server's network interface. This allows the server to remain powered down during idle periods and be spun up dynamically over the network only when infrastructure services are required.

### 8. Network Monitoring via SNMP

End-to-end SNMPv2c is configured across the environment to poll hardware metrics and track subsystem health.

Core Polling Commands:

Bash

```
# System Information
snmpwalk -v 2c -c public <IP> SNMPv2-MIB::sysDescr.0
snmpwalk -v 2c -c public <IP> SNMPv2-MIB::sysUpTime.0

# Hardware & Subsystems
snmpwalk -v 2c -c public <IP> UCD-SNMP-MIB::laLoad           # CPU Load
snmpwalk -v 2c -c public <IP> UCD-SNMP-MIB::memTotalReal     # Total RAM
snmpwalk -v 2c -c public <IP> UCD-SNMP-MIB::dskPercent       # Disk Usage

# Network Interfaces
snmpwalk -v 2c -c public <IP> IF-MIB::ifDescr                # List Interfaces
snmpwalk -v 2c -c public <IP> IF-MIB::ifInOctets             # Inbound Traffic
```

### Appendix A: Unified Process Management Glossary

To effectively manage services across the environment, the following standardized command syntax is utilized. *Note: Replace placeholders like `[process_name]` with the actual resource.*

1. **Start:** Initiate a new process or restart an existing one.
   * *Usage:* `start [process_name]` (e.g., `start backup`)
2. **Stop:** Terminate a running process safely.
   * *Usage:* `stop [process_name]` (e.g., `stop backup`)
3. **Status:** Check the current runtime state of a specific process.
   * *Usage:* `status [process_name]` (e.g., `status backup`)
4. **List:** Enumerate all available processes or resources within a category.
   * *Usage:* `list [category]` (e.g., `list processes`)
5. **Help:** Access detailed syntax and flags for any command.
   * *Usage:* `help [command_name]` (e.g., `help start`)
6. **Log:** Output the activity log or standard output for a specific process.
   * *Usage:* `log [process_name]` (e.g., `log backup`)
7. **Update:** Apply patches or updates to a process or the system.
   * *Usage:* `update [process_name]` (e.g., `update software`)
8. **Remove:** Delete a process, configuration, or resource from the system.
   * *Usage:* `remove [resource_name]` (e.g., `remove file`)
9. **Configure:** Modify operational settings for a process or system component.
   * *Usage:* `configure [setting_name]` (e.g., `configure network`)
10. **Backup:** Create an archive of data or configurations.
    * *Usage:* `backup [data_type]` (e.g., `backup files`)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://belal-ezat.gitbook.io/projects/linux-networking-home-lab.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.