Network Posture — Environments, Trust, and Validation

Contributors rarely work from a single machine. Code moves from a workstation through a workspace to servers at the edge. Each hop has different observers, egress paths, and trust boundaries. Network posture is the practice of knowing which environment you are on, who can see traffic at each layer, and whether probes confirm the region and role you expect.

This guide is general reference for operators and contributors. Planned tooling helps capture snapshots; it does not replace judgment about where secrets live or who you trust on these paths.

Status

Concepts here reference YOZSH CLI design intent. Operating out of many environments with different configurations, paths, and privileges open gaps in know-how or expertise. Tools to probe and validate unlike hosts before misplaced trust compounds into operational risk. yo log network and background JSONL watching are in development; command details live on the log network reference page.

Three Environments

Most YOZSH workflows span three layers:

  [Workstation]  ----remote session---->  [Dev server / workspace]
         |         (SSH, IDE remote)              |
         |         (optional direct deploy)       |
         +---------------- wrangler deploy / CI --> [Production edge]

Each arrow is a trust relationship, not just a network path. That trust accumulates as closed sessions leave persistent access that outlast logins on every machine that has ever connected until someone audits the server and rotates and revokes what should have ended — Access Security (in progress) goes more in depth about SSH keys.

Egress probes classify the host you are measuring; they do not list who still holds a shell path in. Probes and trust reviews both start by naming which layer is in scope. The table maps each hop from the diagram: where that layer usually runs, what its uplink looks like to the internet, and what credentials or ingress it is expected to hold.

Key insight: the three layers are separate environments, not different views of one machine. Each hop has its own uplink, observers, and credential surface — a check on your workstation only describes that workstation’s path to the internet, not the workspace where a build executes or the production edge that serves customers. Logs that look alike across layers are a hint, not proof the hosts share an uplink or role.

Three different “locations”

Probes and tunnels are often confused with physical place. Separate three ideas:

Probes measure egress and nearest edge. They do not infer physical location unless you record it separately (site tag, manual label). The same metro code on workstation and dev host does not mean they are the same machine — region label match ≠ same host.

Trust boundaries when routing data

Security posture starts with who can observe or alter traffic at each hop.

Workstation → development

Typical paths: SSH, VS Code Remote, Tailscale SSH, corporate VPN.

Development → production

Typical paths: wrangler deploy, CI pipelines, git push to deploy hooks.

Workstation → production (direct)

Browser admin, API tokens, or local wrangler deploy skip the dev layer. Document when that is intentional — the trust model differs from “everything through CI.”

Split tunnel vs exit node (Tailscale)

Default Tailscale is split tunnel: only tailnet and advertised subnet traffic use WireGuard; general internet uses the normal ISP path.

With an exit node enabled, selected or all internet traffic may egress via another tailnet device. You trust the exit operator like a commercial VPN for that traffic. Egress probes may then describe the exit’s region and IP, not your home uplink — record whether an exit node was in use when you interpret a snapshot.

Secure tunnels — complementary roles

Tailscale and cloudflared solve different problems. Using both is common; conflating them leads to false confidence about who can reach what and where traffic exits.

• Tailscale answers: “Can I reach my dev box on the tailnet?”
• cloudflared answers: “Can users reach this service through Cloudflare without a public listener?”

Both appear in the YOZSH dev stack as optional devcontainer features. Tunnels change paths — they do not replace the need to validate that a host’s egress and role still match what you expect after you enable them.

Why validate at two layers

No single check answers every posture question. Split private mesh health from internet egress:

Why bother with periodic checks? Tunnels, travel, VPN exit nodes, and new dev workspaces all change fingerprints without announcing themselves. A snapshot when things look wrong — or when policy says to re-verify — catches “this machine now egresses like a datacenter” or “this colo jumped after I enabled exit” before deploy credentials ride the wrong path.

Keep background checks polite. Prefer small HTTPS probes on infrastructure you control, logged on change rather than every few seconds. Reserve deep tailnet diagnostics for ad hoc troubleshooting — not a tight loop against shared relay infrastructure.

Different tools measure different paths. A mesh relay latency report and a CDN edge round-trip both mention regions like “Dallas” on a Texas uplink — that overlap is a hint, not proof they saw the same route. Use both only when you need to reconcile a mismatch.

Probing scenarios — validating operating regions

Use consistent fingerprints plus role tags to ask: is this the environment I think it is?

A — Contributor at home, dev workspace in nearby cloud

Takeaway: nearby region labels on both hosts do not prove they share an uplink. ASN and stability when you travel discriminate home from cloud.

B — Remote IDE or SSH — work happens on the dev server

The UI feels local; builds and posture checks on the laptop describe the thin client only. Instrument the host where code runs for deploy and runtime validation.

The same split applies to RDP, Citrix, and VS Code Remote: network checks on the client describe home uplink, not remote compute. Access is also split: every machine that has ever connected to a shared dev server may still hold a shell path via its SSH key — retiring a laptop does not remove that trust unless someone cleans up the server side.

C — Exit node or tunneled egress

With a Tailscale exit node enabled, egress probes from the same client often show the exit region, not home. That mismatch is worth documenting in any snapshot — tunneled traffic shifts who you trust for metadata and cleartext on non-TLS paths.

D — Deploy from dev vs from workstation

Compare egress and target edge against policy:

• Deploy from dev workspace — expect cloud ASN and colo near build infrastructure.
• Deploy from workstation — expect residential or VPN egress unless CI mediates.

Drift from expected region or ASN warrants review before treating production as unchanged.

E — Cloud gaming (GeForce NOW): what you see vs where work runs

A clearer split than SSH, because there is no shell on the remote side — only a stream.

Setup: The game runs in NVIDIA’s datacenter; your home PC shows video and sends input. The PC is a thin client: it does not run the game’s network stack for game traffic.

Checks on the home PC alone cannot prove the workload is local. They only describe that machine’s uplink. The “local desktop” illusion is application-layer — pixels and input — not shared egress with the GPU host.

The same classification problem applies to RDP, Citrix, and VS Code Remote (scenario B), but GeForce NOW makes the gap obvious: residential fingerprint on the couch, datacenter workload you never SSH into. Tag role=thin-client on the machine you instrument and role=workload on the session host when you control both.

Takeaway: do not treat “this PC looks like home” as “this work runs at home.” Instrument or policy-check where compute executes, not only where the keyboard sits.

Signal matrix

Strongest discriminators: egress IP + ASN; colo/ASN change-only alerts; exit_node_in_use on every line; dual instrumentation (client + workload) when using remote devevelopment or streaming / remote display.

What validation cannot prove: malware, app-level streaming without host metadata, exact routing path, physical room, who still holds SSH keys on a shared server, or intent — only classification and drift for the host you measured.

How yo helps isolate and identify concerns

Planned yo log network packages the kind of validation described above — a repeatable snapshot when you need evidence, not a continuous scanner.

Use snapshots to narrow concerns: unexpected cloud ASN on a machine tagged workstation, colo jump after enabling exit node, stable datacenter fingerprint while you travel (workload is remote). Follow with access review (who still has SSH or deploy access), ACL policy, and checks on the correct host.

Example JSONL shape (planned, abbreviated):

{
  "event": "posture.snapshot",
  "role": "dev-workspace",
  "egress": { "asn": "AS16509", "public_ip": "…" },
  "edges": [{ "provider": "cloudflare", "colo": "DFW", "rtt_ms": 28 }],
  "tailscale": { "exit_node": null, "home_region": "dfw", "udp_ok": true }
}

Protect network.jsonl like auth logs — it may contain IPs and ASN.

Operator practices

1. Tag roles — workstation, dev-workspace, production on every snapshot host.
2. Probe where work runs — not only where the keyboard sits.
3. Log on change — avoid noise; investigate colo, ASN, gateway, and exit-node shifts.
4. ACL discipline — restrict exit node advertisement; review tailnet exposure (Tailscale exit nodes).
5. Authenticate probes — bearer or header on Worker endpoints; rate-limit; do not publish URLs.
6. Separate tunnel roles — Tailscale for device mesh; cloudflared for service ingress; record which path traffic used when interpreting egress.

Quick reference