DEV Community

Cover image for Building and Testing a Mini VPC with Python and Linux Namespaces
Ifeanyi Nworji
Ifeanyi Nworji

Posted on

Building and Testing a Mini VPC with Python and Linux Namespaces

#networking #devops #python #linux

Overview
In this project, I built a Mini Virtual Private Cloud (VPC) system on Linux using nothing but Python and native networking tools.
It mimics real AWS networking — with public/private subnets, NAT, VPC peering, and firewall policies — but all runs locally.

This setup is perfect for DevOps learners and cloud enthusiasts who want to see how networks actually work behind the scenes.


fig.1 VPC network diagram

  • Bridge (br0) → acts like your VPC switch

  • Namespaces → represent isolated networks

  • veth pairs → connect subnets to bridge

  • iptables NAT → allows outbound access only from the public subnet

Step 1: Setup

make setup
Enter fullscreen mode Exit fullscreen mode

Step 2: Create the VPC

make create-vpc VPC_NAME=myvpc BASE_CIDR=10.10.0.0/16
Enter fullscreen mode Exit fullscreen mode

Creates a bridge br-myvpc and enables IP forwarding.

Step 3: Add Subnets

make add-subnets VPC_NAME=myvpc
Enter fullscreen mode Exit fullscreen mode

Creates:

  • myvpc-public → 10.10.1.0/24 (Internet access)

  • myvpc-private → 10.10.2.0/24 (Internal only)

Step 4: Deploy Demo Applications
Run a web app in the public subnet

sudo ip netns exec myvpc-public python3 -m http.server 8080 &
Enter fullscreen mode Exit fullscreen mode

From your host:

curl 10.10.1.2:8080
Enter fullscreen mode Exit fullscreen mode

You should see the directory listing or “Hello from Public Subnet”.

Run a web app in the private subnet

sudo ip netns exec myvpc-private python3 -m http.server 8080 &
Enter fullscreen mode Exit fullscreen mode

From host:

curl 10.10.2.2:8080
Enter fullscreen mode Exit fullscreen mode

You’ll get no response — because private subnets aren’t exposed externally.

Step 5: Validate Connectivity
Communication within the same VPC

sudo ip netns exec myvpc-private ping 10.10.1.2
Enter fullscreen mode Exit fullscreen mode

Works (internal VPC communication).

Internet access from public subnet

sudo ip netns exec myvpc-public ping 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

Works via NAT.

Internet access from private subnet

sudo ip netns exec myvpc-private ping 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

Blocked — no default route to internet.

Step 6: Test Multiple VPCs and Peering
Create two VPCs

make create-vpc VPC_NAME=vpc1 BASE_CIDR=10.20.0.0/16
make create-vpc VPC_NAME=vpc2 BASE_CIDR=10.30.0.0/16
Enter fullscreen mode Exit fullscreen mode

Check isolation

sudo ip netns exec vpc1-public ping 10.30.1.2
Enter fullscreen mode Exit fullscreen mode

Blocked — fully isolated by default.
Peer them

sudo ./vpcctl.py peer-vpc vpc1 vpc2
Enter fullscreen mode Exit fullscreen mode

Now ping again:

sudo ip netns exec vpc1-public ping 10.30.1.2
Enter fullscreen mode Exit fullscreen mode

Works (controlled communication after peering).

Step 7: Apply Security Policies (Firewall)

sudo iptables -A INPUT -s 10.10.2.0/24 -p tcp --dport 22 -j DROP
Enter fullscreen mode Exit fullscreen mode

Policies like:

{"port": 22, "protocol": "tcp", "action": "deny"}
Enter fullscreen mode Exit fullscreen mode

would automatically block SSH access while keeping web traffic open.

Step 8: Cleanup

make delete-vpc VPC_NAME=myvpc
Enter fullscreen mode Exit fullscreen mode

Or

./cleanup.sh
Enter fullscreen mode Exit fullscreen mode

Removes:

  • All namespaces

  • The bridge

  • NAT/firewall rules

Ensures no residual configuration remains.

Github link

Top comments (0)