docs: add enterprise network deployment guide

[okdistribute]

A network deployment guide aimed at the person who has to approve iroh on a corporate network, rather than at the developer shipping the application. The reader assumed here is an IT manager at a small or medium business: wary of what this software will do on their network, not a network specialist, and without an iroh developer sitting next to them.

The structure follows what that reader has to decide. A one-minute summary, a direct answer to whether iroh defeats their firewall, a security and privacy FAQ, and troubleshooting organized by symptom rather than by subsystem. Changes made on the network are separated from changes made in the application, since only the first kind is theirs to make. The framing throughout is STUN and TURN, because anyone who has configured a conferencing system has already reasoned through these trade-offs once.

Facts came from iroh v1 rather than from the existing docs, several of which are stale on this. Worth a check from someone who knows the relay internals:

• Relay connections are HTTPS on 443 upgrading to a WebSocket, with latency probes at GET /ping. Called out for readers running application-aware firewalls, which may permit 443 but block the upgrade.
• Address discovery is UDP 7842. STUN and port 3478 are gone in v1, though troubleshooting.mdx still shows stun_port: 3478 in its sample output. Left alone as separate cleanup.
• Certificate verification uses compiled-in Mozilla roots and ignores the OS trust store, so TLS-intercepting proxies break relay connections until CaTlsConfig::system() is set. This is the most likely thing on the page to bite a real user.
• The pkarr publisher defaults to AddrFilter::relay_only, so internal IP addresses are not published to the public DNS server. Stated plainly in the privacy FAQ, since it is the reassuring answer to a question this audience will definitely ask.
• proxy_from_env() and the relay access config (allowlist, denylist, shared_token, http) did not appear to be documented anywhere.

Two behaviors inferred from reading socket/transports/relay/actor.rs that I would like confirmed, since the multi-site section rests on them. First, that a device connects to the peer's home relay rather than its own. Second, that start_active_relay will dial a relay absent from the local relay map but find no auth token for it, so an authenticated relay refuses the connection. The guide presents the second as the reason to ship identical relay configuration to every site.

Also worth a second opinion on the claim that roughly one connection in ten needs a relay. That came from the existing relay and NAT traversal pages rather than from any measurement I did.

🤖 Generated with Claude Code

[flub]

First, that a device connects to the peer's home relay rather than its own.

Yes, that is correct. You always connect to the home relay of the destination endpoint/the endpoint being dialed.

Second, that start_active_relay will dial a relay absent from the local relay map but find no auth token for it, so an authenticated relay refuses the connection.

Yes, this is also correct. We probably could do with some mechanism to also include auth tokens in EndpointAddr as that's a feature request waiting to happen I guess.

Also worth a second opinion on the claim that roughly one connection in ten needs a relay. That came from the existing relay and NAT traversal pages rather than from any measurement I did.

That's globally probably about true. Though since this is targetting network operators it is worth pointing out that from their side they can configure things so that it is 100% relayed with no successful nat traversal. Given a certain network setup iroh can either holepunch or not. There is no "it can holepunch some of the time on this network" (that would be a bug). But of course the network of the peer also matters which might not be under the same person's control.