Conversation
The server already resolves a connection's remote address back to the node key the tunnel authenticated, but only privately: PeerEnv formats it into TAILCAT_PEER_KEY for subprocesses, and the SSH session handler had a second copy of the same lookup. A Go program embedding tailcat had no way to get the key itself, so it could not tell which of its AllowedClients a connection belonged to, and had to fall back to matching on the tailcat IP. Export it as Server.PeerKey and route both existing callers through it. This also fixes UDP flows. Both copies type-asserted the address to *net.TCPAddr, so the ConnPacketConn handed to OnUDP and OnUDPForward never matched and PeerEnv silently omitted TAILCAT_PEER_KEY for them. PeerKey accepts *net.UDPAddr too. The new test covers both TCP and UDP and fails on the UDP case without this change.
This branch has not been deployed
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
1 participant
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.
tailcat already resolves a connection's remote address back to the node key the
tunnel authenticated, but only privately:
PeerEnvformats it intoTAILCAT_PEER_KEYfor served subprocesses (#78, #89), and the SSH sessionhandler carried a second copy of the same lookup.
A Go program embedding tailcat has no way to get the key. It can parse
PeerEnv's strings, but it cannot map a connection to one of itsAllowedClients: the address-to-key direction ispeerByIP, and thekey-to-address direction is
tcAddrForKey, both unexported. Export the lookupas
Server.PeerKeyand route both existing callers through it, so there is onecopy instead of two.
This also covers UDP flows. Both copies type-asserted the remote address to
*net.TCPAddr, so theConnPacketConnpassed toOnUDPandOnUDPForward,and the per-flow
net.ConnthatServer.Listen's UDP mode returns, nevermatched and got no key. Nothing in cmd/tailcat reaches that path today, since
the CLI's UDP forwarding goes through
ProxyPacketConns, but a library usercalling
PeerEnvorPeerKeyfrom a UDP handler does.PeerKeyaccepts*net.UDPAddrtoo.Where I ran into it: I maintain an ACAP that embeds tailcat on Axis cameras and
lists the clients that have connected, so an address shared further than
intended is visible to the operator. With
AllowedClientspinned, that listcan show an address but not which authorized key it belongs to. Same app
behind #116.
TestPeerKeycovers both TCP and UDP. Reverting only the*net.UDPAddrcasemakes the UDP assertion fail with
ok=falsewhile TCP still passes, so the testgates the bug fix and not just the refactor.
The API change is purely additive: one new method, nothing removed or altered.