ai.oz0/net-diag
For: tenant administrators and plugin users.
ai.oz0/net-diag runs network probes from the node that hosts it. Its oz0-net-diag agent can investigate a report such as "users in Malmö cannot reach the VPN", then explain the fault, numerical evidence and next checks.
| Function | What it does |
|---|---|
oz0_net_diag.dns_lookup | name, record_type (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV, PTR), resolver. A and AAAA without a resolver answer as applications on the node see them, the hosts file included; NXDOMAIN, no answer and timeouts are answers in status |
oz0_net_diag.tcp_check | host, port: a connection to each address (up to four), connected, refused or silent, with times |
oz0_net_diag.http_check | url, method (HEAD or GET): the status, the time and every redirect, followed only to allowed hosts |
oz0_net_diag.tls_check | host, port, server_name: whether the certificate verifies and why not, the names it covers, its issuer, expiry and days left, the protocol and cipher |
oz0_net_diag.trace_route | host, max_hops: each hop with mtr, traceroute or tracepath, whichever the node has |
Every function only reads.
In a sandbox, on a node with the default --plugin-sandbox strict and in a job an outside event started, tls_check goes through the egress proxy, which refuses a tunnel whose TLS names another host than the one it was opened to: a server_name other than host answers with an access-denied alert and a denial on the job. Ask by the name itself, or by the address with no server_name.
Install
Its agent oz0-net-diag asks for the tenant's default model alias with tools, never a vendor's model, so it runs on whichever provider the tenant set up first; map it elsewhere with oz0 model alias set default <provider>/<model>.
oz0 plugin install hub:ai.oz0/net-diag
oz0 tenant egress default vpn.example.com 'intranet.example.com:*'
oz0 run oz0-net-diag "Users in Malmö cannot reach the VPN at vpn.example.com"
What the probes reach
Every target must be on the tenant's egress allowlist, except DNS lookups through the node's own resolver, which go where the node's lookups always go; a named resolver must be allowed too, as 10.0.0.53:53. A refused probe is a tool error that names the host and the command that allows it, and the agent reports it instead of guessing.
Names on the tenant's list may resolve to private addresses, since that is how you diagnose your own network (a name only an agent's or a plugin's list allows reaches public addresses only, inside a sandbox and out); the node itself, its link and cloud metadata services are reached only when the tenant's list names the address.
The probes see the network from the node they run on. Run the agent on a node in the site with the problem: label the
site's nodes and require the label in an overlay of the agent. trace_route needs mtr, traceroute or tracepath on
the node; it says so when there is none.
On a node with sandbox tier 1, whose default is --plugin-sandbox strict, and in a job an outside event started
anywhere, the tool server runs in the sandbox, whose only
network is the node's egress proxy: tcp_check and tls_check go through it by name (CONNECT), http_check sends its
request to it, and dns_lookup and trace_route, which need the node's own network, answer that they cannot run
there.
On a node that must run those two on its own network, its operator chooses --plugin-sandbox auto,
under which the server keeps the host's network and only its own checks hold it to the lists.