Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

et -t does not accept IP address #604

Open
tsunamaru opened this issue Oct 24, 2023 · 3 comments
Open

et -t does not accept IP address #604

tsunamaru opened this issue Oct 24, 2023 · 3 comments
Assignees

Comments

@tsunamaru
Copy link

I'm using ET to port-forward kube-apiserver to my local machine using et -t and looks like it does not accept IP address specified like ${LOCAL_ADDR}":"${LOCAL_PORT}":"${REMOTE_ADDR}":"${REMOTE_PORT}. This is perfectly working combination with SSH, but not with ET.

Some examples:

# will listen on *:10 and forward to *:50005
et -t 10.96.0.1:50005:127.1.1.1:8443 kube-master
# will listen on *:50005 and forward to *:127
et -t 50005:127.1.1.1:8443 kube-master
# will listen on *:50005 and forward to *:8443, doesn't work for me since remote is bind to 127.1.1.1:8443
et -t 50005:8443 kube-master

SSH example:

# will listen on 10.96.0.1:50005 and forward to 127.1.1.1:8443, just as it should be
ssh -L 10.96.0.1:50005:127.1.1.1:8443 kube-master

Would be really nice to see such functionality present in EternalTerminal!

@MisterTea
Copy link
Owner

Interesting, thanks for the clear issue description. I don't believe ip addresses are supported at all. I think what's happening is the "10.96.0.1" is being passed to stoi and turned into "10", and "50005:127.1.1.1:8443" is being turned into "50005". Stoi is very tolerant of malformed numbers.

Would you be willing to write this PR? There's a few parts:

  1. Change the parsing code here to accept ip addresses: https://github.com/MisterTea/EternalTerminal/blob/master/src/base/TunnelUtils.cpp#L4
  2. Remove this check
  3. If the name exists, use it here instead of hardcoding localhost:

@tsunamaru
Copy link
Author

@MisterTea would love to help with PR, but sadly I don't know C++
Hope somebody can pick this up.

Do you accept bounties, by the way? If yes, I would happily sponsor implementation of this feature.

@jshort jshort self-assigned this May 6, 2024
@jshort
Copy link
Collaborator

jshort commented May 7, 2024

Looking this over. Unfortunately due to the the history of how --tunnel and --reversetunnel work (i.e. source:dest or source-range:dest-range), coming up with a syntax similar to vanilla ssh -L will likely be non-intuitive. However, the legacy behavior hinges on a single colon (":") in the cli argument so I can have this new feature request assume standard ssh -L argument semantics if there is more than one colon. Let me play around with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants