My Experience with college server.

Hello people!

Ever felt the pain of wanting to deploy a side project but getting bogged down by cloud configs, billing alarms, and complex DevOps tools? So did I. That's why I built KWS.

But this isn't just a story about an application. It's a story about taking that application from a codebase on my laptop to a physical server humming in a college rack, navigating network policies, and building a real-world, self-hosted cloud platform. Buckle up!

🚀 What is KWS?

KWS is a self-hosted cloud platform that lets developers and students deploy their apps in secure, containerized environments instantly. Think of it as a mini-Heroku + VS Code Server + Fly.io, all running on your own hardware.

Here’s what it offers:

• 🔒 Secure VPN-Based Access: Every container is isolated and accessible via a private WireGuard VPN.
• 💻 Browser-Based VS Code: Every instance gets a live VS Code IDE at https://<container-id>.kwscloud.in. No setup needed.
• 🗃️ Built-In PostgreSQL: Managed databases from the dashboard with scoped user privileges. No need to run DBs in your app container.
• 🌐 One-Click Public Hosting: Make your app public in seconds at https://<your-app>.kwscloud.in. No manual Nginx configs!
• 🧰 Full Instance Control: Start, stop, redeploy, and monitor everything from a clean dashboard.

It's perfect for hackathons, college courses, or anyone who wants real deployment power without the cloud bill.

---

🏗️ The Adventure: Hosting KWS on College Hardware

Our college bought a new server for KWS. The mission was simple: get it from the box to the internet. The execution, however, was a fantastic lesson in practical networking.

Step 1: The Hypervisor - My Foundation

I started with bare metal. I chose Proxmox VE (a fantastic Type 1 hypervisor) as my base layer. It allows me to create and manage virtual machines (VMs) easily, giving me the flexibility to host KWS and other future services.

Step 2: Navigating the Network - The DMZ

This was the first big lesson in enterprise IT. You can't just plug a server into the main campus network.

• The Problem: The main LAN is trusted. A vulnerable server on it could risk the entire college network.
• The Solution: The DMZ (Demilitarized Zone), a segregated network for public-facing services. The college's firewall strictly controls traffic between the DMZ, the internet, and the internal LAN.

The college assigned me a private IP from the DMZ range (like 10.10.20.x) for my Proxmox host. They then set up firewall rules on their edge device to NAT and forward public traffic for ports 80, 443, and 51820 (WireGuard) to my Proxmox host's DMZ IP.

Step 3: The Internal Challenge - No DMZ IPs for VMs

Here's where it got interesting. The college's policy prevented me from getting additional DMZ IPs for our individual VMs. I had to get creative.

My Solution: Create a private network inside Proxmox for all our VMs.

I created a new Linux Bridge (vmbr1) in Proxmox and gave it its own private subnet: 192.168.69.0/29.

Why a /29? It provides 6 usable IP addresses. One for the Proxmox gateway, leaving five for VMs. It's small, secure, and perfect for my needs.

# /etc/network/interfaces on Proxmox
auto vmbr1
iface vmbr1 inet static
    address 192.168.69.1/29 # Proxmox is the gateway
    bridge_ports none
    bridge_stp off
    bridge_fd 0

Step 4: Making the Magic Happen with iptables

Now I had a problem. My KWS VM (and others) lived on the 192.168.69.0/29 network, utterly invisible to the outside world.

The solution? Turn the Proxmox host into a router.

1. Enable IP Forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -p

2. Set up NAT (Masquerading) so the VMs can access the internet outbound:

iptables -t nat -A POSTROUTING -s 192.168.69.0/29 -o vmbr0 -j MASQUERADE

3. Set up Port Forwarding (DNAT) to direct public traffic to the correct internal VM. This was the key to making KWS accessible.

HTTPS:

iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to-destination 192.168.69.2:443
iptables -A FORWARD -p tcp -d 192.168.69.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Wireguard VPN:

iptables -t nat -A PREROUTING -i vmbr0 -p udp --dport 51820 -j DNAT --to-destination 192.168.69.2:51820 

iptables -A FORWARD -p udp -d 192.168.69.2 --dport 51820 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

4. Make the rules persistent:

apt install iptables-persistent
iptables-save > /etc/iptables/rules.v4

Step 5: The Grand Finale - Wildcard SSL

The main domain for the college is kamarajengg.edu.in, and it already has a wildcard SSL (*.kamarajengg.edu.in). This allows kws.kamarajengg.edu.in to work with HTTPS. However, apps like app1.kws.kamarajengg.edu.in cannot get HTTPS because wildcard certificates only support one level, and these are subdomains of a subdomain.

To solve this, I purchased my own domain kwscloud.in, set up a DNS challenge in Cloudflare (where my DNS is managed), and obtained a wildcard SSL (*.kwscloud.in). Now, apps hosted in kws.kamarajengg.edu.in are securely accessible under *.kwscloud.in.

📖 The Architecture Diagram:

Here’s a simplified view of how traffic flows to a user's app:

🎓 Lessons Learned & Conclusion

This project was an incredible deep dive into practical networking, security, and system administration. I learned:

• The Value of the DMZ: Isolating public services is a critical security practice.
• NAT and Port Forwarding are Foundational: Understanding iptables is like gaining a networking superpower.
• Planning is Key: Carefully planning your IP addressing scheme from the start prevents headaches later.
• The Power of Self-Hosting: There's immense value in controlling your own infrastructure, both for learning and for independence from cloud vendors.