As I was curious after reading and implementing the User-Defined Routing (UDR) and subnet-slicing concepts previously, I couldn't wait to test this out under live traffic conditions. Theory is fine on paper, but as an infrastructure engineer, I don't truly trust a network design until I break it, throw live packets at it, and look at the raw terminal logs.
Tonight, I stepped completely out of the textbooks and moved assets onto the cloud field. I deployed two live virtual servers inside my Singapore network sandbox, faced down strict regional quota walls, bypassed local internet restrictions, and operationally proved that my traffic hijacking detour rule works perfectly under real production conditions.
Here is the step-by-step engineering log of how I did it, the real-world troubleshooting steps I took, and the underlying mechanics explained so simply that anyone can understand it.
🏛️The Day 8 Deployment Strategy: Setting the Field
To safely test our custom detour signpost without opening our network to the public internet, I had to deploy two distinct virtual machines into my sandbox environment. To keep my billing running at exactly ₹0/hour, I utilized Microsoft's newer, high-performance AMD free-tier eligible engine size (Standard_B2ats_v2).
💡The Analogy: The Front Security Lobby vs. The Locked Back Vault
Hub-Mgmt-VM (The Front Lobby Desk): This machine sits right inside the public entryway of our network (Management_SEA_Subnet). It is given an official, fixed public street address (Static Public IP) so that administrators can find it and log into it from the outside world.
Spoke-App-VM (The Hidden Back Vault): This machine sits deep inside the isolated production floor (App_Prod_Subnet) within the Spoke VNet. To maintain strict security, this machine is given absolutely no public front door. It has no public IP address, making it completely invisible to the internet and dependent on our hub-and-spoke bridge to talk to the world.
🛠️The Step-by-Step Command-Line Execution
Instead of clicking through the graphics of the Azure Portal GUI, I typed the deployment scripts manually into the Azure Cloud Shell to burn the syntax directly into my muscle memory.
- Generating the Golden Cryptographic Login Keys
Before spinning up the servers, I generated a pair of secure cryptographic keys. In professional enterprise security, we completely ban weak, guessable text passwords. Instead, we use advanced mathematics to generate an interconnected Private Golden Key (kept in our pocket) and a matching Public Lock (bolted onto the server door).
`bash
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
`
🚙Code Decoder (Line-by-Line):
ssh-keygen - Starts the security engine tool to manufacture secure digital keys and locks.
-t rsa - Tells the computer to use the industry-standard RSA math algorithm for maximum security.
-b 2048 - Makes the lock 2,048 bits thick, which would take supercomputers billions of years to crack.
-f ~/.ssh/id_rsa - Saves your private golden key as id_rsa and your public lock as id_rsa.pub in a hidden folder.
-N "" - Assigns a blank passphrase so our automation code can read the keys instantly without annoying prompts.
- Provisioning the Entryway Jump Box (Hub Machine)
I launched the administrative entryway machine directly inside the Singapore network layout using our AMD free-tier compute profile:
`bash
az vm create -g Marathahalli_Lab_RG -n Hub-Mgmt-VM --location southeastasia --vnet-name Sec_Hub_SEA_VNet --subnet Management_SEA_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address-allocation static
`
🚙Code Decoder (Line-by-Line):
az vm create - Orders Azure to go to its physical hardware racks and carve out a new virtual server.
-g Marathahalli_Lab_RG - Groups all the server assets (disks, cards) inside my regional resource folder.
-n Hub-Mgmt-VM - Labels this machine "Hub-Mgmt-VM" so we can easily track it in logs.
--location southeastasia - Bypasses local data center hardware shortages by building the machine straight in Singapore.
--vnet-name Sec_Hub_SEA_VNet - Plugs this machine's network card directly into our central Hub network.
--subnet Management_SEA_Subnet - Drops the machine into the dedicated room reserved for administrative management desks.
--image Ubuntu2204 - Installs a clean, production-ready version of the Ubuntu Linux 22.04 operating system.
--size Standard_B2ats_v2 - Our Zero-Cost Safeguard; chooses a dual-core AMD size that is 100% free-tier eligible.
--admin-username abhishek - Creates the master administrator user profile inside the Linux operating system.
--ssh-key-values ~/.ssh/id_rsa.pub - Takes the public lock file we created earlier and bolts it onto the server login gate.
--public-ip-address-allocation static - Gives this lobby desk a fixed, unchanging internet address so we can always connect from home.
- Provisioning the Completely Private Workload (Spoke Machine)
Next, I launched our isolated application instance. Notice the empty quotes at the very end of the script—this explicitly commands Azure to deny this machine a public IP door, keeping it completely private:
`bash
az vm create -g Marathahalli_Lab_RG -n Spoke-App-VM --location southeastasia --vnet-name Sec_Spoke_SEA_VNet --subnet App_Prod_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address ""
`
🚙Code Decoder (Line-by-Line):
--vnet-name Sec_Spoke_SEA_VNet - Targets our Spoke Network instead of our Hub network.
--subnet App_Prod_Subnet - Drops this machine onto our isolated production factory floor block.
--public-ip-address "" - The Isolation Shield; passing empty quotes forbids Azure from giving this server a public IP address.
📊 The Routing Validation Blueprint: The Live Tests
Once both servers were live, it was time to run our live validation test plan. We need to mathematically and operationally prove that our traffic hijacking detour rules are working.
` ===================================================================================
= THE LIVE TRAFFIC FLOW DIAGRAM =
===================================================================================
[ Home/Cloud Terminal ] --(Passes Through)--> [ Hub Lobby Jump Box: 10.0.1.4 ]
|
(VNet Peering Bridge)
|
v
[ Internet: 8.8.8.8 ] <---(100% PACKET LOSS!)--- [ Private Spoke VM: 10.1.1.4 ]
^ |
| (User-Defined Route)
| |
+=========== (HIJACKED TO BLACK HOLE!) ===========+
`
Test 1: The Master Itinerary Manifest Audit (Effective Routes Query)
Before sending a packet, I queried Azure’s network routing engine directly to show me what map the Spoke network interface was using under the hood:
`bash
az network nic show-effective-route-table -g Marathahalli_Lab_RG -n Spoke-App-VMVMNic -o table
`
🚙Code Decoder (Line-by-Line):
az network nic - Targets the virtual Network Interface Card attached to our private Spoke server.
show-effective-route-table - Interrogates Azure's live routing processor to show the active traffic map.
-n Spoke-App-VMVMNic - Targets the specific system name of our Spoke machine's network adapter card.
-o table - Orders the output messy code to cleanly rearrange itself into a beautiful grid with headers.
The result was an absolute architectural victory! The table showed our manual detour route for 0.0.0.0/0 sitting as Active, while Azure’s native, unmonitored default highway to the internet was marked as completely Invalid.
Test 2: The Inner Private Walkway Check (The Peering Bridge Jump)
I used secure SSH Agent Forwarding (ssh -A) to pass through my public entryway lobby box and jump straight onto the internal private IP of our isolated Spoke machine (10.1.1.4).
Once inside the Spoke machine's shell prompt, I executed an internal connectivity check back to the Hub:
`bash
ping -c 4 10.0.1.4
`
🚙Code Decoder (Line-by-Line):
ping - Sends small network test packets to an IP address to see if it is awake.
-c 4 - Sets a count limit flag; stops sending test packets automatically after 4 attempts.
10.0.1.4 - Targets the private internal IP coordinate of our Hub management desk room.
The packets zoomed across the private VNet Peering footbridge instantly, returning a perfect 0% packet loss statistic. This proved that our internal private communication lines were completely healthy and operational.
Test 3: The Black Hole Validation Check (The Ultimate Hijack Proof)
Now, the grand finale. While standing inside the private Spoke machine, I attempted to send a packet out to Google's public internet server:
`bash
ping -c 4 8.8.8.8
`
🚙Code Decoder (Line-by-Line):
8.8.8.8 - Targets a well-known public internet server (Google's Public DNS infrastructure).
The terminal hung for a moment, and then returned exactly 100% packet loss.
In ordinary desktop computing, losing all your packets looks like a failure. But in Cloud Network Security Engineering, this is a spectacular win! It operationally proves that our custom detour sign successfully intercepted the outbound internet packet at the subnet boundary and shoved it down our secure detour corridor. Because we haven't built the actual firewall software engine at that destination endpoint yet, the traffic terminates safely at that empty boundary, confirming that our perimeter isolation is working flawlessly.
💰Financial Discipline Check: Protecting the Trial Runway
By maintaining strict enterprise resource boundaries and leveraging Azure's dual-core AMD free-tier eligible compute allocations, our active sandbox running cost sits at exactly ₹0 per hour. This leaves my full promotional credit balance safe at ~₹18,909 for our upcoming security engine deployments.
🏁Day 8 Wrap-Up
Tonight was a massive architectural leap forward. By typing out raw CLI statements, resolving core quotas, and validating data-plane packet paths step by step, I am locking in the exact hands-on engineering confidence needed for senior enterprise technical panels.
The isolated sandbox field is fully verified. Next up, we deploy our central security engine—the live Azure Native Firewall—to capture that black-holed traffic, inspect it, and safely bridge our secure fortress out to the public web!
🛠️Safe Infrastructure Resting Script
To keep our active billing runway perfectly protected while we draft our notes, I executed a master deallocation script from the Cloud Shell Control Tower to put both machines into deep freeze at zero cost:
`bash
az vm deallocate -g Marathahalli_Lab_RG --ids $(az vm list -g Marathahalli_Lab_RG --query "[].id" -o tsv) --no-wait
`
🚙Code Decoder (Line-by-Line):
az vm deallocate - Commands Azure to stop compute billing entirely by releasing our CPU/RAM chips back into the shared datacenter pool.
$(az vm list ... --query "[].id" -o tsv) - Automatically compiles a neat list of every single virtual machine ID inside our resource group folder.
--no-wait - Forces the command to process silently in the background so we can instantly turn off our computer.
Onward and upward! 🚀🔥
Top comments (0)