personal_interest_mirrors/nebula
1
0
Fork 0
mirror of https://github.com/slackhq/nebula.git synced 2025-11-09 00:43:57 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated LightHouse addrMap (markdown)

John Maguire 2024-10-23 17:09:30 -04:00
parent 9f6d9480d1
commit 6f3bfa642e
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
LightHouse-addrMap.md

@ -2,7 +2,7 @@ This is an incomplete, point-in-time, high-level overview of how `LightHouse.add
When Nebula starts, it constructs a single `LightHouse` struct used for the duration of the process. It persists across reloads.
A LigthHouse contains an `addrMap` (`map[iputil.VpnIp]*RemoteList`) mapping all of the VPN IPs it is tracking to their associated underlays. `addrMap` lives for the duration of the process.
A LightHouse contains an `addrMap` (`map[iputil.VpnIp]*RemoteList`) mapping all of the VPN IPs it is tracking to their associated underlays. `addrMap` lives for the duration of the process.
`RemoteList` structs contains a deduplicated set of addresses (`addrs`) and relays (`relays`) that can be used to talk to a given VPN IP. These two fields are populated by `unlockedCollect` and deduped by `unlockedSort`, based on the `cache` and `hostnameResults` objects).) `RemoteList` entries are deleted by `DeleteVpnIp` when a tunnel is closed or detected dead (unless the VPN IP is in the static host map - we can't delete these or we wouldn't learn them again until Nebula is reloaded!) They are created on the fly by `unlockedGetRemoteList` if they don't already exist for a given VPN IP, e.g. inside `addStaticRemotes` , `QueryCache`, `addCalculatedRemotes`, `handleHostUpdateInformation`, `handleHostQueryReply`, etc.