pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-02-22 04:46:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Define resources and small formating updates

Browse Source
This commit is contained in:
Owen
2025-12-10 18:02:03 -05:00
parent ea68e3a6bc
commit de61a00717
11 changed files with 73 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
manage/resources/private/access.mdx Normal file
View File

@@ -0,0 +1,14 @@
---
title: "Access"
description: "Only allow access to Resources to specific users, roles, and machines"
---
When a client connects into an organization they will **NOT** have access to any Resources by default. Access must be explicitly granted to users, roles, or machines for a WireGuard tunnel to be established to the site hosting the Resource. The Client will show no peers unless access is granted.
Access can be granted in several ways:
* **Roles:** Assign access to Resources to specific roles. Any user or machine with that role will gain access to the Resource when they connect.
* **Users:** Assign access to Resources to specific users. Only those users will gain access to the Resource when they connect.
* **Machines:** Assign access to Resources to specific machines. Only those machines will gain access to the Resource when they connect. Note that machines can not be put into roles.
When removing access to a resource, the client will automatically tear down the WireGuard tunnel to that Resource if there are no other Resources accessible on that site.

16
manage/resources/private/alias.mdx
View File

@@ -7,6 +7,18 @@ Aliases provide a secondary, user-friendly address for any of your Resources, al
For instance, a router with the address `10.0.0.1` could be assigned the alias `router.internal`, and users could connect using either. Aliases are accessible to anyone who has access to the Resource, and they are exclusively accessible when connected with a Pangolin client, meaning they function without requiring any external DNS record setup. Furthermore, aliases are protocol agnostic, which means they will work with any network protocol, essentially acting as a pseudo-A record for an address that is only functional within the Pangolin environment.
# Disable Aliases
## CIDRs Vs. IPs
Aliases work
A alias can only be created for a Resource that is a single host (IP or FQDN). Aliases cannot be created for Resources that are CIDR ranges because it would be ambiguous which host within the range the alias should point to.
## Domain Structure
Since aliases cannot be single-label domains, you must avoid using domain names that do not contain a dot (e.g., `pangolin`). A domain like `pangolin.net`, which includes a dot, is acceptable. Instead of a single-label domain, you should consider using a subdomain of a domain you control, such as `router.mywebsite.com`, or an existing private/internal domain name, like `router.internal` or `router.corp`.
## Custom Upstream DNS
Aliases work by overriding the DNS of your computer running the client so that all DNS requests are sent to the Pangolin client for resolution. The dns server on your computer is typically `100.96.128.1` which will forward request to an upstream server. By default, we use `9.9.9.9`, but this upstream address can be configured using [the flag](/manage/clients/configure-client) in the cli / olm or in the client settings.
## Disable Aliases
If you wish to disable this behavior and prevent aliases from being resolved and leave your DNS alone, you can do so by adding [the flag](/manage/clients/configure-client) to the cli / olm or disable override dns in the client settings.

4
manage/resources/private/cidr.mdx
View File

@@ -1,4 +0,0 @@
---
title: "CIDRs"
description: "Provide access to an entire network range"
---

27
manage/resources/private/destinations.mdx Normal file
View File

@@ -0,0 +1,27 @@
---
title: "Destinations"
description: "Understand connection options to the remote network"
---
A Resource's **destination** can be defined in several ways:
* **Fully Qualified Domain Name (FQDN):** For example, `host.autoco.internal`.
* **IP Address:** For example, `10.1.0.35`.
* **IP CIDR Range:** For example, `10.1.0.0/16`.
When defining a Resource with an FQDN, the Pangolin site will resolve the FQDN to an IP address on the remote network. This allows you to create Resources that point to hosts whose IP addresses may change over time, as long as the FQDN remains consistent.
When defining a Resource with an IP address, the Pangolin client will connect directly to that specific IP address on the remote network. It will insert routes for that single IP address into the network route table of the host when users connect with the client.
When defining a Resource with a CIDR range, all IP addresses within that range will be accessible to users who have been granted access to the Resource. This is useful for providing access to entire subnets or network segments. It will insert routes for that single IP address into the network route table of the host when users connect with the client.
### Additional Notes on Resource Destinations
* **Reserved IP Addresses:** The Pangolin client reserves the CGNAT subnet 100.96.128.0/24. Accessing resources via an IP address within this reserved range will be blocked by the client, though its use is uncommon. This range can be configured for newly created orgs in the self-hosted Pangolin configuration file.
* **Resource Destination Resolution:** The configured address of the Resource is resolved by the site the resource points to. Make sure the site can resolve the address correctly.
### What about overlaps?
Pangolin smooths away overlapping networks and arbitrarily chooses a single site to resolve the IP address or range to. This is because we want connection requests to any Resource to be as simple as possible for the end users: when they connect to a particular IP address or FQDN, Pangolin figures out which site to send it to and the end user never needs to figure this out.
It is recommended that you create overlapping resources only if absolutely required. If you do, use [Aliases](/manage/resources/private/alias) to explicitly defined which host should be used for a given FQDN or IP address and use the alias to connect.

15
manage/resources/private/host.mdx
View File

@@ -1,15 +0,0 @@
---
title: "Hosts"
description: "Provide access to a specific host on the network"
---
### What about overlaps?
Pangolin smooths away overlapping networks and arbitrarily chooses a single site to resolve the IP address or range to. This is because we want connection requests to any Resource to be as simple as possible for the end users: when they connect to a particular IP address or FQDN, Pangolin figures out which site to send it to and the end user never needs to figure this out.
It is recommended that you create overlapping resources only if absolutely required. If you do, use [Aliases](/manage/resources/private/alias) to explicitly defined which host should be used for a given FQDN or IP address and use the alias to connect.

4
manage/resources/private/overview.mdx
View File

@@ -1,4 +0,0 @@
---
title: "Overview"
description: "Private resources are only accessible when connected with a Pangolin client"
---

2
manage/resources/understanding-resources.mdx
View File

@@ -41,7 +41,7 @@ HTTP resources are also identity and context aware, meaning you can create polic
Raw resources are a way to proxy any TCP and UDP traffic through the Pangolin reverse proxy. Instead of a fully qualified domain name and certificate, these resources are bound to one or more ports on the Pangolin host.
Since these resources are not protocol aware and are publically proxied, they do not support identity and context policies and rules.
Since these resources are not protocol aware and are publicly proxied, they do not support identity and context policies and rules.
### Private Resources