Peers previously advertised overlay interface (tsun0) addresses as physical
candidate endpoints for both iroh discovery and tcp-tls announcements. When an
intermediate tunnel was active between two peers (e.g., between a host and a VM),
iroh probes to the remote peer's overlay address were routed through the existing
overlay, causing iroh to select the overlay IP itself as a 'direct' endpoint.
This caused recursive tunneling (QUIC over WireGuard over TLS) and confusing
status output showing peers connecting to their own overlay IP addresses.
Additionally, in tsunagi status, peer rows were displayed with unaligned
columns, mixing control plane status and data plane metrics in a way that was
difficult to scan.
Key improvements:
- In crates/tsunagi/src/net.rs, add an AddrFilter to the iroh EndpointBuilder
to dynamically filter out any local addresses assigned to tsun* overlay
interfaces before publishing to address discovery services (DHT/pkarr/STUN).
- In crates/tsunagi-tcp-tls/src/plugin.rs, exclude tsun* interfaces from
local_ip_candidates() so overlay IPs are never advertised as physical
TCP endpoints.
- In crates/tsunagi-cli/src/main.rs, exclude tsun* interfaces from
netwatch_addresses() so the local addresses section reflects only actual
physical/host network interfaces.
- In crates/tsunagi-cli/src/main.rs, update member_row() to format member
details with aligned columnar layout: the overlay IP is placed first and
padded, followed by control plane transport and latency, and line 2 pads
tunnel metrics so that the data link endpoint (via ...) aligns vertically.
Validation on Linux:
- cargo fmt --all -- --check passed.
- cargo clippy --locked --workspace --all-targets -- -D warnings passed.
- cargo test --locked --workspace --all-targets --jobs 2 -- --test-threads=2 passed (349 tests passed).
Aleksandr Bogomiakov
2ed447ae86