reverse_tunnel: propagate initiator worker and connection ids#46232
Open
roll-no-21 wants to merge 1 commit into
Open
reverse_tunnel: propagate initiator worker and connection ids#46232roll-no-21 wants to merge 1 commit into
roll-no-21 wants to merge 1 commit into
Conversation
The reverse-tunnel handshake carried no way to tell apart tunnels opened by different workers or connections of the same initiator. Add two optional handshake headers, x-envoy-reverse-tunnel-worker-id (the initiator worker dispatcher name, e.g. worker_2) and x-envoy-reverse-tunnel-connection-id (the initiator's per-connection id), and surface them on both ends. Downstream (initiator): the identifiers are sent in the handshake and exposed in the initiator access log via the new worker_id and connection_id fields of the envoy.reverse_tunnel.initiator dynamic metadata namespace. The connection id is captured at socket handoff so it is available for the connection_closed event after the connection object is gone. Upstream (acceptor): the network filter parses the two headers (best effort; empty for older initiators) and threads them into the ReverseTunnelLifecycleInfo. They are surfaced on every lifecycle event as the initiator_worker_id and initiator_connection_id fields of the envoy.reverse_tunnel.lifecycle dynamic metadata namespace and as the envoy.reverse_tunnel.initiator_worker_id / envoy.reverse_tunnel.initiator_connection_id connection filter-state keys, distinct from the acceptor's own worker field. Signed-off-by: Krishna Sharma <k.sharma@databricks.com> Co-authored-by: Isaac Signed-off-by: Krishna Sharma <krishnagpl2001@gmail.com>
roll-no-21
marked this pull request as ready for review
July 17, 2026 14:33
roll-no-21
requested review from
agrawroh,
botengyao and
yanavlasov
as code owners
July 17, 2026 14:34
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit Message: reverse_tunnel: propagate initiator worker and connection ids
Additional Description:
The reverse-tunnel handshake carried no way to distinguish tunnels opened by different worker threads or connections of the same initiator. This adds two optional handshake headers and surfaces them on both ends so operators can tell tunnels apart and correlate a tunnel across the initiator and acceptor.
Downstream (initiator).
RCConnectionWrapper::connect()now sendsx-envoy-reverse-tunnel-worker-id(the initiator worker dispatcher name, e.g.worker_2) andx-envoy-reverse-tunnel-connection-id(the initiator's per-connection id). Both are exposed in the initiator access log via the newworker_idandconnection_idfields of theenvoy.reverse_tunnel.initiatordynamic metadata namespace. The connection id is captured at socket handoff so it is still available for theconnection_closedevent after the connection object is gone.Upstream (acceptor). The
envoy.filters.network.reverse_tunnelfilter parses the two headers (best-effort; empty for older initiators) and threads them throughaddConnectionSocketintoReverseTunnelLifecycleInfo. They are emitted on every reverse-tunnel lifecycle event as theinitiator_worker_idandinitiator_connection_idfields of theenvoy.reverse_tunnel.lifecycledynamic metadata namespace, and as theenvoy.reverse_tunnel.initiator_worker_id/envoy.reverse_tunnel.initiator_connection_idconnection filter-state keys. These are distinct from the acceptor's ownworkerfield.Both directions are additive and backward compatible: an initiator that does not send the headers yields empty values, and no configuration changes are required.
Risk Level: Low
Testing: Unit tests added/updated across the downstream initiator, the acceptor socket manager, the lifecycle filter, and the network filter parse path. Full
//test/extensions/bootstrap/reverse_tunnel/...,//test/extensions/filters/network/reverse_tunnel/..., and//test/extensions/clusters/reverse_connection/...suites pass.Docs Changes: Updated
docs/root/configuration/other_features/reverse_tunnel.rst(lifecycle metadata fields + filter-state keys, initiator access-log field table) and the initiator example config.Release Notes: Added a
new_featureschangelog entry.This pull request and its description were written by Isaac.