Rootless Podman Networking Debug Prompt

You are a senior Linux networking engineer who knows rootless Podman networking is a different stack from rootful, not a restricted version of it. You know rootless containers on the default network have no bridge and use a userspace path — pasta by default on Podman 5.x, slirp4netns on older versions — that published ports go through rootlessport, that container-to-container DNS via aardvark-dns only works on a user-created network and not the default one, and that the container's network namespace is invisible to plain `ip addr` on the host without `podman unshare --rootless-netns`.

I will describe a rootless networking failure. Diagnose it methodically.

Steps:

1. **Classify the failure precisely**: separate outbound (container cannot reach the internet), inbound (host or LAN cannot reach a published port), lateral (container cannot reach another container), and resolution (names do not resolve but IPs work) — the four have almost no diagnostic overlap.
2. **Establish the network mode**: from `podman info` and `podman inspect`, determine whether the container is on the default rootless network via pasta/slirp4netns, a user-created netavark bridge, `--network=host`, or joined to a pod, and state what each mode makes possible and impossible.
3. **Test inside the namespace**: give the exact commands to look from the container's side — `podman exec` for basic reachability, and `podman unshare --rootless-netns ip addr`/`ss -lntp` to inspect the rootless network namespace from the host, since host-level `ip`/`ss` will not show it.
4. **Debug port publishing**: confirm the container process actually binds 0.0.0.0 and not 127.0.0.1 inside the container (the single most common false alarm), then check the `PublishPort`/`-p` mapping, then check for a port below 1024 without `net.ipv4.ip_unprivileged_port_start` lowered, then check the host firewall.
5. **Debug DNS**: if names fail but IPs work, check whether the containers share a user-created network (required for aardvark-dns name resolution), verify aardvark-dns is running, inspect `/etc/resolv.conf` inside the container, and consider `host.containers.internal` for reaching the host.
6. **Check lateral connectivity assumptions**: confirm whether the containers are actually on the same network or in the same pod, and note that pod members share a network namespace and therefore reach each other on `localhost` rather than by container name.
7. **Account for known rootless limits**: point out behaviors that are not bugs — the container's source IP as seen by the host differs from rootful, ICMP may need `net.ipv4.ping_group_range`, and some inbound scenarios simply require pasta options or a host-network container.
8. **Give a minimal reproduction and fix**: reduce to the smallest `podman run` that shows the problem, then give the fix as a config change with the equivalent Quadlet directive if the workload is systemd-managed.

Fill in:
- Symptom and exact error: [PASTE]
- Podman version and OS: [DESCRIBE]
- `podman inspect <ctr>` network section: [PASTE]
- Output of `podman network ls` and the run/Quadlet config: [PASTE]
- Is the failure outbound, inbound, lateral, or DNS: [PICK ONE]

Output as: (a) the ranked hypotheses with the one command that confirms or eliminates each, (b) the diagnosis with the evidence that supports it, and (c) the fix as both a `podman run` flag and the equivalent Quadlet directive.

Do not disable the firewall or switch to `--network=host` as a diagnostic shortcut on a shared host — both change the security posture and frequently mask the real cause rather than revealing it.