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

Expand on why lighthouse.hosts should be empty on lighthouses, and provide reasons to break this in src/data/config-reference.md #31

Open
JonTheNiceGuy opened this issue Jun 28, 2022 · 3 comments

Comments

@JonTheNiceGuy
Copy link

Relevant code section

Please correct this if I'm wrong, but from memory, there are reasons why not to leave lighthouse.hosts empty on a host acting as a lighthouse - perhaps you have multiple lighthouses providing services, e.g.

Lighthouse 1: 192.0.2.1 serves DNS on port 53, NTP on port 123, HTTP on port 80, RDP on port 3389. Consumes SSH from lighthouse 2.
Lighthouse 2: 192.0.2.2 serves DNS on port 53, NTP on port 123 and SSH on port 22. Consumes HTTP from lighthouse 1.
Node 1: 192.0.2.3 consumes all of the above services

In this context, Lighthouse 1 and Lighthouse 2 both need to know about each other, however, they shouldn't list their OWN IP address.

@johnmaguire
Copy link
Member

johnmaguire commented Jun 28, 2022

@JonTheNiceGuy AFAIK lighthouse.hosts configures which Nebules hosts are routinely sent IP addresses through which other nodes can try to connect to them.

If Lighthouse 1 needs a route to Lighthouse 2, I believe it should be possible to define it in static_host_map without configuring it as a Lighthouse.

In this scenario, Node 1 would have both Lighthouse 1 and Lighthouse 2 listed in both lighthouse.hosts and static_host_map as it will want to send its IPs to both lighthouses.

Is there a reason to add the respective Lighthouses in the lighthouse.hosts section of each other that I'm missing?

@JonTheNiceGuy
Copy link
Author

There are so many fundamental underpinnings of this product I seem to misunderstand 😁 But it's awesome getting to learn more about it!

I thought I needed to list them in both static_host_map (so it could find the other lighthouse on the "real" internet) and also in lighthouse.hosts (so it can advertise itself properly, including being added to the DNS).

I tend to run the Nebula DNS service on my lighthouses, and then add them as DNS servers so that all the hosts can lookup by the hostname on the certificate. If I've added both lighthouses, but I've set Lighthouse_1 as the first DNS server, and Lighthouse_2 as the second DNS server, when I do a DNS lookup for the A record relating to Lighthouse_2, Lighthouse_1 will return NXDOMAIN for Lighthouse_2 if the two lighthouses aren't registering themselves in each other's list of lighthouses... or am I wrong? Always happy to be corrected on things like this!

@nbrownus
Copy link

All that is needed for lighthouse_1 to know how to reply to DNS queries about lighthouse_2 is that the two machines have had a tunnel established.

In your setup, static_host_map is necessary and having each lighthouse configured to know of the other in lighthouse.hosts only serves to establish that tunnel as soon as possible. You could remove the lighthouse.hosts config on both machines and run a ping to the other lighthouse after starting nebula to achieve the same result.

nebula itself doesn't currently have a way to "prime" tunnels aside from lighthouse.hosts but it seems like a worthwhile feature.

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

No branches or pull requests

3 participants