Route a packet. Inspect a translation. Ship a release. Explore the decisions that turn infrastructure into a dependable digital experience.
INTERACTIVE ENGINEERING LABSynthetic data · no live traffic
Beginner mode follows what happens and why it matters. Switch to Technical mode for addresses, headers, connection state, and protocol details.
Choose a device and send a request.
All addresses, headers, logs, timings and metrics below are illustrative. Nothing sends real packets or changes production.
DEVICE → CLOUD SERVER → DATABASE → DEVICE
One request. The complete data flow.
Follow a device through NAT and the Internet to a cloud application server. Watch the server query its private database, build a response, and return it to the correct device.
Choose where the application server and database run. Database access stays private in every layout.
1. Device → NAT → Internet
2. Ingress ↔ application server
3. Server ↔ private database
4. Response → NAT → device
NETWORK TOPOLOGY
Drag to pan · arrow keys pan when the diagram is focused · + / − to zoom · select a packet to inspect
→ Request← Response× Blocked / lostDNS: separate exchange
Live NAT / connection-tracking table
Only the selected TCP/443 connections are shown. A highlighted row matches the visible exchange.
Device
Inside source
Translated public source
Remote endpoint
State
No active mappings. Send a request to create one.
Laptop A and Mobile B both start at port 51514. Watch PAT assign them different public ports.
Port forwarding, CGNAT, IPv6—and what this model leaves out
Outbound connection tracking allows valid replies without inbound port forwarding. Port forwarding is a separate explicit inbound rule. Carrier-grade NAT may add another translation at the ISP and prevent ordinary inbound hosting. IPv6 commonly uses globally routable addressing without NAT, but still needs a correctly configured firewall. This model uses simplified endpoint-dependent reply matching and a 30-second demo idle lifetime; real NAT policies, timeouts and TCP closing states vary.
Public-looking addresses are reserved documentation ranges: 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24. They are not live Internet destinations.
FRAMES ≠ PACKETS ≠ HTTP MESSAGES
Inspect the layers. Keep the boundaries clear.
Choose a captured illustrative packet or step through the network journey. Only its endpoints can read TLS-protected HTTP content.
SELECTED PACKET / SEGMENT
No packet captured yet
Send a request in Network & NAT, then select a packet on its path.
Link-layer MAC addresses apply to the shown hop. Routers replace link headers across routed links. A logical request/response may span many packets.
ENCAPSULATION / DECAPSULATION
HTTP method, headers, body Application meaning
TLS records Encrypted application data
TCP segment Ports, sequence, acknowledgments
IP packet Source, destination, TTL
Local-link frame Next-hop MAC addresses
Choose a layer to compare its purpose.
HTTP request / response explorer
Readable HTTP/1.1 examples. HTTP/2 uses binary framing; HTTP/3 uses QUIC over UDP. The NAT demo selects HTTPS over TCP.
Request · visible at the client / TLS endpoint
Response · visible at the TLS endpoint / client
PUBLIC EDGE. PRIVATE SERVICES.
Build the right infrastructure for the job.
Profiles show different components rather than adding every cloud service to every design. Select a node to inspect its responsibilities and failure modes.
Who actually sees which IP?
The gateway public IP, public edge IP, proxy peer and private origin IP are different addresses.
Forwarded visitor headers and TLS boundaries
CF-Connecting-IP, X-Forwarded-For, X-Forwarded-Proto and standardized Forwarded describe the original client or scheme only when supplied through a correctly configured trusted proxy chain. Untrusted callers can forge these headers. Network peer IP is not the same thing as a validated forwarded visitor address.
A reverse proxy often terminates one TLS connection and creates another to the origin. With Cloudflare Tunnel the connector establishes the tunnel outbound; requests and replies use that established bidirectional transport. The connector-to-application hop must be secured separately as the deployment requires.
Put the security boundary to work
Safe scenarios change the diagram, response outcome, audit event and simulated monitoring.
Pass the checks, approve a promotion, and compare how deployment strategies preserve—or interrupt—serving capacity.
V1 SERVING
Production waits for evidence.
Run the pipeline to move a synthetic commit through review, tests, build, staging and approval.
Shared live database · preserved across application releases
CAPACITY & SAFETY
Readiness before traffic.
Blue/green needs capacity for both versions. Rolling updates need enough healthy replicas and suitable rollout limits. A single-instance stop/start has a service gap. Backward-compatible migrations and connection draining matter in every overlapping release.
A successful HTTP health check is a gate, not a guarantee against every functional defect. Rollback needs a retained compatible version; it does not reverse new database records.
Where delivery and operations tools fit
GitHub Actions or Azure DevOps can orchestrate CI/CD. Docker packages immutable images. Terraform and other infrastructure-as-code tools version infrastructure changes. A secrets manager supplies runtime credentials. New Relic-style APM, traces and centralized logs help investigate performance. These are educational examples—not claims of installed integrations.
From an incident to a verified recovery
All dashboard values and logs are simulated; they react to the selected security event, pipeline and incident.
SIMULATED TELEMETRY
INCIDENT RESPONSE
No open incident
Trigger a synthetic outage or slowdown, then investigate, identify the cause, apply a correction and verify recovery.
Sanitized simulation event log
No events yet. This is not a live production log.
Three architectures. Three clear boundaries.
Where does your application live?
Explore a separate high-level diagram for each cloud model. These are illustrative designs, not a map of Dhruvexa production infrastructure. Select a component to learn what it does.
A public-cloud provider operates the resource pool. Public cloud does not mean every service has a public IP: application targets and databases can stay private.
Select a component above for its technical role and business value.
02
Private cloud
A dedicated cloud environment for one organization.
HIGH-LEVEL MODEL
A private-cloud control plane provisions a dedicated pool of compute, network and storage resources. This is more than placing a single server behind a private IP. Access can be internal or through explicitly protected ingress.
Distinct public and private cloud environments are joined by configured connectivity. In this example the app runs in public cloud and queries a private-cloud database. Routing, latency, identity and firewall policies must work across both environments.
Workload placement · controlled data location · connected operations
Select a component above for its technical role and business value.
Thoughtful engineering. Visible value.
Behind every seamless digital experience is thoughtful engineering.
Build secure, scalable, and reliable digital solutions with Dhruvexa.