-
Notifications
You must be signed in to change notification settings - Fork 276
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
docs(connlib): add more inline docs to connlib's state #5105
Changes from all commits
9563d7a
4cd35e5
8fcb752
3f0ca62
027be05
f1ee306
39ee471
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -281,37 +281,61 @@ fn send_dns_answer( | |
} | ||
} | ||
|
||
/// A sans-IO implementation of a Client's functionality. | ||
/// | ||
/// Internally, this composes a [`snownet::ClientNode`] with firezone's policy engine around resources. | ||
/// Clients differ from gateways in that they also implement a DNS resolver for DNS resources. | ||
/// They also initiate connections to Gateways based on packets sent to Resources. Gateways only accept incoming connections. | ||
pub struct ClientState { | ||
/// Manages wireguard tunnels to gateways. | ||
node: ClientNode<GatewayId, RelayId>, | ||
/// All gateways we are connected to and the associated, connection-specific state. | ||
peers: PeerStore<GatewayId, GatewayOnClient>, | ||
/// Which Resources we are trying to connect to. | ||
awaiting_connection: HashMap<ResourceId, AwaitingConnectionDetails>, | ||
|
||
/// Tracks which gateway to use for a particular Resource. | ||
resources_gateways: HashMap<ResourceId, GatewayId>, | ||
/// The site a gateway belongs to. | ||
gateways_site: HashMap<GatewayId, SiteId>, | ||
/// The online/offline status of a site. | ||
sites_status: HashMap<SiteId, Status>, | ||
|
||
pub dns_resources_internal_ips: HashMap<DnsResource, HashSet<IpAddr>>, | ||
/// All DNS resources we know about, indexed by their domain (could be wildcard domain like `*.mycompany.com`). | ||
dns_resources: HashMap<String, ResourceDescriptionDns>, | ||
/// All CIDR resources we know about, indexed by the IP range they cover (like `1.1.0.0/8`). | ||
cidr_resources: IpNetworkTable<ResourceDescriptionCidr>, | ||
pub resource_ids: HashMap<ResourceId, ResourceDescription>, | ||
pub deferred_dns_queries: HashMap<(DnsResource, Rtype), IpPacket<'static>>, | ||
|
||
peers: PeerStore<GatewayId, GatewayOnClient>, | ||
/// All resources indexed by their ID. | ||
resource_ids: HashMap<ResourceId, ResourceDescription>, | ||
|
||
node: ClientNode<GatewayId, RelayId>, | ||
|
||
pub ip_provider: IpProvider, | ||
|
||
dns_mapping: BiMap<IpAddr, DnsServer>, | ||
|
||
buffered_events: VecDeque<ClientEvent>, | ||
interface_config: Option<InterfaceConfig>, | ||
buffered_packets: VecDeque<IpPacket<'static>>, | ||
/// The DNS resolvers configured on the system outside of connlib. | ||
system_resolvers: Vec<IpAddr>, | ||
|
||
/// DNS queries that we need to forward to the system resolver. | ||
buffered_dns_queries: VecDeque<DnsQuery<'static>>, | ||
|
||
/// The (internal) IPs we have assigned for a certain DNS resource. | ||
/// | ||
/// We assign one internal IP per externally resolved IP. | ||
dns_resources_internal_ips: HashMap<DnsResource, HashSet<IpAddr>>, | ||
/// DNS queries we can only answer once we have connected to the resource. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is that connecting to the Resource or to the Gateway? It's the Gateway that resolves DNS, and the Resource doesn't do anything except accepting incoming connections after we've resolved it, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is for the special case where the configured upstream DNS server is a resource itself. @conectado Can probably answer this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are for any DNS query that hasn't been answered by the gateway yet, we use this to create a response later on. we don't really connect to a resource ever, but we have the gateway grant access to a resource, at that point it's resolved. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah I forgot to address this one. Will send another PR once it is merged. |
||
/// | ||
/// See [`dns::ResolveStrategy`] for details. | ||
deferred_dns_queries: HashMap<(DnsResource, Rtype), IpPacket<'static>>, | ||
/// Hands out IPs for DNS resources. | ||
ip_provider: IpProvider, | ||
/// Maps from connlib-assigned IP of a DNS server back to the originally configured system DNS resolver. | ||
dns_mapping: BiMap<IpAddr, DnsServer>, | ||
/// When to next refresh DNS resources. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does this do? Do we redo DNS resolving even while connected to a Resource? Or is this the DNS TTL? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question, let me dig into this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is the former. I clarified this in a comment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the only reason we don't use the TTL here is because we don't have it, we would need to use something like hickory on the gateway too to obtain it. with the DNS refactor we are doing now this will go away anyways and refreshing will look really different with a whole new set of problems 😛 |
||
/// | ||
/// "Refreshing" DNS resources means triggering a new DNS lookup for this domain on the gateway. | ||
next_dns_refresh: Option<Instant>, | ||
|
||
system_resolvers: Vec<IpAddr>, | ||
/// Configuration of the TUN device, when it is up. | ||
interface_config: Option<InterfaceConfig>, | ||
|
||
gateways_site: HashMap<GatewayId, SiteId>, | ||
sites_status: HashMap<SiteId, Status>, | ||
buffered_events: VecDeque<ClientEvent>, | ||
buffered_packets: VecDeque<IpPacket<'static>>, | ||
} | ||
|
||
#[derive(Debug, Clone, PartialEq, Eq)] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did
cargo doc --no-deps --open -p firezone-tunnel
and this link didn't show up?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess because snownet is not in the workspace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to build the docs for the entire
rust/
directory. Then the links work.