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

Advertising localhost IP to trusted Prysm node #31

Closed
cortze opened this issue Jun 17, 2024 · 6 comments · Fixed by #33
Closed

Advertising localhost IP to trusted Prysm node #31

cortze opened this issue Jun 17, 2024 · 6 comments · Fixed by #33

Comments

@cortze
Copy link
Contributor

cortze commented Jun 17, 2024

Description

Hermes currently advertises only the private address when connecting to the local Prysm node. This makes local testing harder, as the Prysm node might not always be on the same local network (target for the production deployment at AWS or similar).

// register ourselves as a trusted peer by submitting our private ip address
privateMaddr, err := n.host.PrivateListenMaddr()
    if err != nil {
    return err
}

slog.Info("Adding ourselves as a trusted peer to Prysm", tele.LogAttrPeerID(n.host.ID()), "maddr", privateMaddr)
    if err := n.pryClient.AddTrustedPeer(ctx, n.host.ID(), privateMaddr); err != nil {
    return fmt.Errorf("failed adding ourself as trusted peer: %w", err)
}

Creating an SSH tunnel with the Hermes port reverse-tunneled is convenient. However, this requires the Hermes instance to advertise the localhost IP, which opens a few questions:

  • Should Hermes also advertise both addresses? it would mean adding two peers as trusted on the Prysm side (with the private connections always failing, or vice-versa)
  • Should we just use the localhost one?
  • Should the user choose it with a new flag like: --local-prysm=true/false?
@guillaumemichel
Copy link
Contributor

What do you mean by advertise the localhost IP?

@cortze
Copy link
Contributor Author

cortze commented Jun 18, 2024

When hermes adds itself as a trusted node at the control Prysm node, it has to set a multi-address that Prysm can also ping to.
Prysm generally rejects the first connection from hermes -> prysm, but it tries to open the connection back to the given multi-address.
If we want to open a SSH tunnel between the local hermes and the remote prysm to test changes (with a reverse port forwarding for the hermes p2p port), the current private address that hermes advertises won't be reachable by Prysm, as both are in different private networks.
Thus, establishing the connection requires hermes to share the 127.0.0.1 IP inside the trusted multi-address.

@guillaumemichel
Copy link
Contributor

OK I see. Would it be a security issue to have Hermes advertise both addresses? It seems to be the easiest solution.

Alternatively the --local-prysm=true/false flag also seems a good option.

@cortze
Copy link
Contributor Author

cortze commented Jun 19, 2024

On the security side, I would say that there is nothing to worry about, as this is just how Hermes lets Prysm know how to reach it back.

It could indeed advertise both addresses, the private and localhost ones, but it means that Prysm will constantly try to connect both addresses while one of them is always unreachable 🤷🏽

@guillaumemichel
Copy link
Contributor

Alright, then maybe the flag is best in this case

@cortze
Copy link
Contributor Author

cortze commented Jun 19, 2024

Alright, then maybe the flag is best in this case

Nice, I'll set it to the private one as default, and change it to the localhost one if the flag --local-trusted-address is given

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

Successfully merging a pull request may close this issue.

2 participants